h:commandLink onclick broken for Windows CE user agents

[ren-zhijun-oracle]

When using a simple , when using a regular web browser (FireFox, Safari, etc.) everything works fine. Clicking the link results in the JS code being called, then the link functioning as expected.

However, when changing the user agent of the browser (FireFox was used) to "Windows CE", different functionality occurs. h:commandLink, when rendered, neglects the developer-specified onclick, and does not provide the functionality anymore. Looking at the generated HTML code, the custom JS code cannot be found anywhere.

Environment

Operating System: All Platform: All

Affected Versions

[1.2_09 BETA1]

[ren-zhijun-oracle]

• Issue Imported From: https://github.com/javaserverfaces/mojarra/issues/876
• Original Issue Raised By:@javaserverfaces
• Original Issue Assigned To: @edburns
• Original Issue Closed By:@javaserverfaces

[ren-zhijun-oracle]

@javaserverfaces Commented Reported by keyhack

[ren-zhijun-oracle]

@javaserverfaces Commented @edburns said: Take ownership.

[ren-zhijun-oracle]

@javaserverfaces Commented @edburns said: edburns keyhack: Thanks, so you observer the bug when you use the same browser but just change the user-agent? keyhack correct keyhack the problem also happened on a real Windows CE device edburns keyhack: Pardon my ignorance, but is there some plugin that lets one manually set the user-agent? keyhack edburns: if you are using FireFox, in the address bar simply type "about:config", then hit enter. Then you can search for "agent", and you can replace FireFox with Windows CE, and it changes it instantly

[ren-zhijun-oracle]

@javaserverfaces Commented driscoll said: I'm unaware of anything that checks user-agent in our code. And this sounds like an implementation that's too clever by half - checking user agent to see if JavaScript is allowed, and changing the output code to remove JavaScript if it thinks it's not supported.

The other possibility is a proxy that strips it for certain UAs, but that doesn't seem like the issue.

I did a quick test in JSF 2.0, and as expected this didn't happen. That code hasn't changed since 1.2 (I know, I'm the one changing it), so it's unlikely that this is our bug.

What's the setup? What version of JSF, what server, any other code installed?

[ren-zhijun-oracle]

@javaserverfaces Commented @rlubke said: I'm in agreement with Jim. Nothing in the 1.2 code base does any user agent checking, so we'll always render the same content no matter the client device type.

If you'd like to verify this for yourself (or prove us wrong) use a utility like wireshark to capture the HTTP traffic between the server and client. I'm sure you'll see the expected markup in the capture.

[ren-zhijun-oracle]

@javaserverfaces Commented keyhack said: Created an attachment (id=712) User-Agent: Firefox/3.0.4

[ren-zhijun-oracle]

@javaserverfaces Commented keyhack said: Created an attachment (id=713) User-Agent: Windows CE

[ren-zhijun-oracle]

@javaserverfaces Commented keyhack said: Created an attachment (id=714) diff of test_firefox.txt and test_windows_ce.txt

[ren-zhijun-oracle]

@javaserverfaces Commented keyhack said: I've attached the HTML generated when using FireFox 3.0. As you can see in the source, there is a function being used called createCookie(). That was defined in the original XHTML as such:

When switching the User-Agent to "Windows CE", you can see different HTML is generated in the attached test_windows_ce.txt. (You can also view the diff at test_diff.txt)

Notice that createCookie is no longer defined anywhere in the document.

The JARs are are included in the WAR are: activemq-4.1.0.jar ajax4jsf-1.1.0.jar antlr-2.7.6.jar aspectjweaver-1.5.3.jar avalon-framework-4.1.3.jar cglib-2.2_beta1_nodep.jar commons-beanutils-1.7.0.jar commons-chain-1.1.jar commons-codec-1.3.jar commons-collections-3.2.jar commons-dbcp-1.2.2.jar commons-digester-1.6.jar commons-httpclient-3.1.jar commons-logging-1.1.jar commons-pool-1.3.jar concurrent-1.3.4.jar device-personality-0.0.11-SNAPSHOT.jar dom4j-1.6.1.jar ejb3-persistence-3.0.jar el-api-1.2_04-b10-p01.jar el-ri-1.2_04-b10-p01.jar flexjson-1.6.jar hibernate-3.3.1.GA.jar hibernate-annotations-3.4.0.GA.jar hibernate-annotations-commons-3.4.0.GA.jar httpunit-1.6.2.jar javassist-3.4.GA.jar jaxen-1.1.jar jdom-1.0.jar jsf-api-1.2_09-b01.jar jsf-facelets-1.1.11.jar jsf-framework-0.0.9-SNAPSHOT.jar jsf-impl-1.2_09-b01.jar jsf-tlds-1.2_04-b10-p01.jar jstl-1.1.0-D13.jar jta-1.1.jar jtidy-4aug2000r7-dev.jar log4j-1.2.14.jar logkit-1.0.1.jar mvel-1.3.3-java1.5.jar mysql-connector-java-5.0.4.jar ojdbc14-9.0.2.0.0.jar opslogic-common-scripts-1.0.jar oscache-2.3.jar pollvault-api-client-0.0.7.jar portlet-api-1.0.jar shale-remoting-1.0.4.jar slf4j-api-1.5.5.jar slf4j-log4j12-1.5.5.jar smartfrog-3.12.000.jar smws-0.0.1-SNAPSHOT-objects.jar snmp4j-1.8.1.jar snmpconnector-0.0.10-SNAPSHOT.jar spring-2.0.8.jar standard-1.1.2.jar whirlycache-1.0.1.jar xalan-2.7.0.jar xercesImpl-2.9.0.jar xml-apis-2.9.0.jar xom-1.1.jar xpp3_min-1.1.4c.jar xstream-1.3.jar

[ren-zhijun-oracle]

@javaserverfaces Commented @rlubke said: Can you reproduce this in a bare-bones application? Perhaps you have an addon that is affecting the result?

If the result is the same between your application and the barebones application, then I'd say use something like wireshark to capture the network traffic between the server and client. My suspicion is you'll find the content sent by the server will be the same, but the Firefox is munging the results based on the configured user-agent.

If you're not able to reproduce it using a bare-bones application, then you've got an addon that is taking action based on the user-agent and may provide a custom renderer for such cases. You'd have to contact the author of the addon to get a fix.

[ren-zhijun-oracle]

@javaserverfaces Commented driscoll said: The statement:

"document.forms['j_id42'].submit();return false;"

Isn't something that we emit. That means something else is emitting that.

Now, that could be one of the many, many jars that you bundle in. I'm unfamiliar with the function of all of them. And I know at least some of them modify the behavior of JSF.

It's also possible it's your container - though that seems unlikely, given what you've told us. (You still haven't mentioned what the container is, btw.)

Here's a test to prove that it isn't our code - it's the same one I used:

Make up a simple file, with a user specified onclick on a commandLink. Use ONLY the JSF jars. No ajax4jsf, no avalon, no spring, no device-personality (which sounds like the thing that would change behavior on a user-agent, doesn't it?).

You'll see that the user specified onclick is wrapped the same regardless of user-agent.

Now, to debug who's monkeying with your page, you'll have to add back in the things that you've listed below. Eventually, you'll get to one, and discover that's the one that's changing your page. Since I don't know the codebase of each of them, I'm afraid that I can't guess who that'd be - though as I said, I'd look first at something like device-personality, which sounds guilty, or ajax4jsf, which is designed to set up a page differently than standard JSF.

[ren-zhijun-oracle]

@javaserverfaces Commented @rlubke said: From Keyhack on IRC:

well, in our custom HtmlCommandLink renderer (which I did not realize we had), we were replacing the onClick code with custom code, and neglecting that the developer may have specified their own custom code. Closing this issue out.

[ren-zhijun-oracle]

@javaserverfaces Commented @manfredriem said: Closing issue out

[ren-zhijun-oracle]

@javaserverfaces Commented File: test_diff.txt Attached By: keyhack

[ren-zhijun-oracle]

@javaserverfaces Commented File: test_firefox.txt Attached By: keyhack

[ren-zhijun-oracle]

@javaserverfaces Commented File: test_windows_ce.txt Attached By: keyhack

[ren-zhijun-oracle]

@javaserverfaces Commented This issue was imported from java.net JIRA JAVASERVERFACES-872

[ren-zhijun-oracle]

@javaserverfaces Commented Marked as incomplete on Thursday, July 1st 2010, 3:09:26 am