After adding Html5RenderKitFactory fails in setting second level managed bean property on Chrome

[GoogleCodeExporter]

After adding the Html5RenderKitFactory, on chrome a second level managed bean 
property is not set.

I added the following to my faces-config.xml:

    <render-kit-factory>org.omnifaces.renderkit.Html5RenderKitFactory</render-kit-factory>

My xhtml looks like this:

<a4j:outputPanel id="testpanel" layout="block">

     Voornaam: <h:inputText value="#{testBean.zoekOpdracht.voornaam}"
                  id="naam" label="Roepnaam/voornaam" maxlength="100" 
                />

        <a4j:commandLink value="Test" 
                            render="testoutput" id="testKnop" />

My managed bean looks like this:

@ManagedBean
@ViewScoped
public class TesetBean {

    private Zoekopdracht zoekOpdracht = new Zoekopdracht();

    public Zoekopdracht getZoekOpdracht() {
        return this.zoekOpdracht;
    }

    public void setZoekOpdracht(Zoekopdracht zoekOpdracht) {
        this.zoekOpdracht = zoekOpdracht;
    }

I expect the voornaam property to be set on the ZoekOpdracht class after 
clicking the a4j:commandLink. 

On chrome this doesn't happen. On firefox and ie it does work!

After removing the Html5RenderKitFactory factory, the setter is working again.

I'm using Omnifaces 1.4.1
I'm using JSF 2 Mojorra bundled with JBoss EAP 6: Mojarra 2.1.7-jbossorg-2 
I'm using Richfaces 4.3.2

Original issue reported on code.google.com by ekkelenk...@gmail.com on 28 May 2013 at 8:20

[GoogleCodeExporter]

We've never faced this kind of problem, at least not with standard JSF nor 
PrimeFaces.

The only known issue with Html5RenderKit is that HTML5 specific input types 
will fail in all browsers when using <f:ajax> on Mojarra versions until with 
2.1.13. 

When I have time, I will look closer at it using the specified JSF/RichFaces 
version.

Original comment by balusc on 28 May 2013 at 12:21

[GoogleCodeExporter]

Rudie, thanks for your report. 

One small comment, even though both Bauke and me are Dutch and can read your 
code perfectly well, this is an project for international users and for 
everyone who doesn't speak Dutch the source you posted will look like 
gibberish. If possible, please translate example code to English whenever you 
post it on places like this. Thanks! ;)

Original comment by arjan.tijms on 28 May 2013 at 9:34

[GoogleCodeExporter]

Hi,

For your information, i made a simple test project using the richfaces maven 
archetype where you can reproduce the issue. If you want me to upload it 
somewhere, please let me know.

I was testing on an old version of firefox. After upgrading to the latest 
version (21.0), it fails on firefox as well. 

Tested with omnifaces:

IE 8.0 : OK.
Firefox 21.0: fails
Chrome 27.0: fails

Tested without omnifaces:

IE 8.0 : OK.
Firefox 21.0: OK
Chrome 27.0: OK

Original comment by ekkelenk...@gmail.com on 29 May 2013 at 8:32

[GoogleCodeExporter]

One more thing I noticed, the issue only appears when actually using a HTML 5 
tag.

After removing the type="search" attribute with omnifaces enabled, the h:input 
text is actually bound to the backing bean. 
Looks like the a4j:commandLink has the same issue as f:ajax  ?

In the posted example I see the type="search" is missing. This should be added 
to reproduce the isse.

Original comment by ekkelenk...@gmail.com on 29 May 2013 at 10:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yes, definitely upgrade Mojarra to at least 2.1.14.

As this problem is not related to OmniFaces, I'll close the ticket as Invalid. 
This issue is mentioned in the known issues list 
https://code.google.com/p/omnifaces/wiki/KnownIssues

Original comment by balusc on 29 May 2013 at 10:39

[GoogleCodeExporter]

Hi,

Too bad. In JBoss EAP6 you cannot upgrade to a higher version of Mojarra. You 
have to use 2.1.7.
Are you sure it is the same issue as the f:ajax issue? Since it does work in 
IE8....

Original comment by ekkelenk...@gmail.com on 29 May 2013 at 11:18

[GoogleCodeExporter]

You can definitely upgrade Mojarra in EAP6. We're currently running 2.1.22 in 
EAP6.0.1 for zeef.com. 

As to IE8 (and the older Firefox), they simply do not support HTML5 inputs. The 
input type="search" is just been interpreted as input type="text" in HTML DOM.

Original comment by balusc on 29 May 2013 at 11:41

[GoogleCodeExporter]

Thanks for your feedback!

I'm really interested to know how you managed to get a higher mojarra version 
in EAP 6? We're still running EAP 6.0. It packages 2.1.7 as default and 
packaging a Mojarra version in de war fails. Has this been fixed in the EAP 
6.0.1 version?

Thanx in advance,

Rudie.

Original comment by ekkelenk...@gmail.com on 29 May 2013 at 11:51

[GoogleCodeExporter]

Packaging Mojarra in WAR indeed fails. You need to upgrade it in JBoss itself.

- Download Mojarra 2.1.22 API and impl files: 
  - https://maven.java.net/content/repositories/releases/com/sun/faces/jsf-api/2.1.22/jsf-api-2.1.22.jar
  - https://maven.java.net/content/repositories/releases/com/sun/faces/jsf-impl/2.1.22/jsf-impl-2.1.22.jar
- Make sure that JBoss is shutdown.
- Update JSF API in /modules/javax/faces/api/main:
  - Delete or backup the old JAR file.
  - Delete the old .index file (JBoss will autocreate one).
  - Put jsf-api-2.1.22.jar file in there.
  - Edit module.xml file:
    - If absent, add <module name="com.sun.jsf-impl"/> to <dependencies>
    - Edit <resource-root> to specify the new file name <resource-root path="jsf-api-2.1.22.jar"/>
- Update JSF impl in /modules/com/sun/jsf-impl/main:
  - Delete or backup the old JAR file.
  - Delete the old .index file (JBoss will autocreate one).
  - Put jsf-impl-2.1.22.jar file in there.
  - Edit module.xml file:
    - Edit <resource-root> to specify the new file name <resource-root path="jsf-impl-2.1.22.jar"/> 
- Cleanup JBoss cache/work data just to make sure that there's nothing hanging 
and colliding:
  - Trash all contents of /standalone/data (expect of custom data folders like folder containing uploaded files)
  - Trash all contents of /standalone/deployments
  - Trash all contents of /standalone/tmp 

Original comment by balusc on 29 May 2013 at 11:56

[GoogleCodeExporter]

Thanks a lot! I'm gonna give that a try.

Much appreciated!

Original comment by ekkelenk...@gmail.com on 29 May 2013 at 12:02