Please find attached a demo application

How to import to Eclipse:
file -> import -> existing project into workspace -> select archieve file -> finish

How to verify the mojarra bug:
1. Please remove the icefaces-ee-2.0.0-INSIEME2.jar and icefaces-ee-compat-2.0.0-INSIEME2.jar from to /WEB-INF/lib
2. Start the server
3. go to: http://localhost:8080/icefacesSupport/JSFBugCommandButton.xhtml
4. Follow instuctions
5. Patch the com.sun.faces.renderkit.html_basic.ButtonRenderer as descibred above
6. Start the server again
7. go to: http://localhost:8080/icefacesSupport/JSFBugCommandButton.xhtml
8. Follow instuctions

How to verify the icefaces bug:
1. Please add the icefaces-ee-2.0.0-INSIEME2.jar and icefaces-ee-compat-2.0.0-INSIEME2.jar to /WEB-INF/lib
2. Start the server
3. go to: http://localhost:8080/icefacesSupport/ICEfacesBugCommandLink.xhtml
4. Follow instuctions

summa summarum:

• If ICESOFT fixes the issue with the h:commandLink in combination with f:ajax disabled=true the h:commandButton stills works but an f:param tag can't be attached to it but at least to h:commandLink's
• If the mojarra guys fix the mentioned h:commandButton problem f:param tags can be applied but h:commandButton in combination with f:ajax disabled=true doesnt work and of course the h:commandLink as well
• If ICESOFT AND the mojarra guys fix both isses: Everything works! ICESOFT should just pay attention that after the mojarra fix a h:commandButton has the onclick="mojarra.jsfcljs(...) function applied as the h:commandLink has it right now

The following does not include the parameters due to mojarra disabling ajax features on the component; effectively they are disabling JavaScript when they are disabling Ajax, which is a reasonable interpretation (and related to some current difficulties with MyFaces).

<h:commandButton value="button"
actionListener="#

">
<f:param name="paramname" value="paramvalue" />
<f:ajax disabled="true" />
</h:commandButton>

For this use case we likely need a different mechanism for "disabling Ajax" on the command button. However, this depends on how mojarra implements the setting of parameters: if they are injected into the form as hidden fields, then a non-Ajax post will work. If they are passed as parameters to jsf.ajax.request, then the parameters will not be available to the standard form POST.

Hi Ted,

You mentioned: "effectively they are disabling JavaScript when they are disabling Ajax". In my opinion mojarra should still add the onclick function -> mojarra.jsfcljs(... ) to the h:commandButton. Thats why I think there might be a bug in "com.sun.faces.renderkit.html_basic.ButtonRenderer: Line 137: RenderKitUtils.renderOnclick( , TRUE instead of FALSE)". Then you'll get the same behaviour for the h:commandButton as the h:commandLink:

<h:commandLink value="link"
actionListener="#

">
<f:param name="paramname" value="paramvalue" />
<f:ajax disabled="true" />
</h:commandLink >
=> This code still puts an mojarra.jsfcljs(...) to the commandLink and makes sure the parameters are rendered as hidden fields and it does not perfrom a ajax request.

Hi Ted,

thanks for the patch. unfortunatelly it is not gonna work for the following scenarios:

<h:commandLink id="btn5" action="#

" >
<f:ajax disabled="true" />
<span>
<h:outputText value="what about me"></h:outputText>
</span>
<f:param name="testParam" value="testValue" />
</h:commandLink>

due the problem that the triggeredBy() function returns the SPAN element rather than the commandLink itself and thus the isAjaxDisabled function fails again...

what I did so far as an very ugly workaround for your patch:
if (toLowerCase(element.tagName) == "form") {
element = triggeredBy($event(event, element));
while (toLowerCase(element.tagName) != "a" && toLowerCase(element.tagName) != "input")

}

if (isAjaxDisabled(element)) {
....

btw: it seems that our commandLinks (see example above that comment) don't work in Firefox Version 5.0: Looks like the method triggeredBy(...) does not return the correct element (in our case the form is returned)

In this case triggeredBy() is returning the incorrect value; we will need to investigate a fix for that as well.

The following patch has been checked in:

Index: core/src/main/javascript/application.js
===================================================================
— core/src/main/javascript/application.js (revision 26183)
+++ core/src/main/javascript/application.js (working copy)
@@ -362,7 +362,23 @@
//hijack browser form submit, instead submit through an Ajax request
f.nativeSubmit = f.submit;
f.submit = function() {

• submit(null, f);
  + var theEvent = null;
  + if (typeof(event) != 'undefined') { + theEvent = event; + }

  else if (window.event)

  { + theEvent = window.event; + }

  else

  Unknown macro: {+ //very bizzarre hack to extract parameters from high up+ //on the call stack to obtain the current Event on Firefox+ //this is sensitive to the depth of the call stack so+ //it may eventually be necessary to walk up rather than+ //test a specific caller+ var maybeEvent = arguments.callee.caller.caller.arguments[0];+ if (typeof(maybeEvent.target) != 'undefined') { + theEvent = maybeEvent; + }+ }

  + submit(theEvent, f);
  };
  each(['onkeydown', 'onkeypress', 'onkeyup', 'onclick', 'ondblclick', 'onchange'], function(name) {
  f[name] = function(e)

  { Index: core/src/main/javascript/submit.js =================================================================== --- core/src/main/javascript/submit.js (revision 26183) +++ core/src/main/javascript/submit.js (working copy) @@ -32,9 +32,8 @@ return toLowerCase(element.nodeName) == 'form' ? element : enclosingForm(element); }

• function isAjaxDisabled(element) {
  + function isAjaxDisabled(formID, element) {
  var elementID = element.id;
• var formID = formOf(element).id;
  //lookup element that contains the list of elements that have AJAX submission disabled
  var disablingMarker = document.getElementById(formID + ":ajaxDisabled");
  return disablingMarker && contains(split(trim(disablingMarker.value), ' '), elementID);
  @@ -186,14 +185,36 @@
  var removePrefix = 'patch-';

fullSubmit = function(execute, render, event, element, additionalParameters, callbacks) {

• if (isAjaxDisabled(element)) {
• var f = formOf(element);
  + var f = null;
  + var eventElement = (event.currentTarget) ? event.currentTarget :
  + triggeredBy($event(event, element));
  + if (toLowerCase(element.tagName) == "form") { + f = element; + }

  else

  { + f = formOf(element); + }

  + var formID = f.id;
  + //if the element has ajaxDisabled or any parent has ajaxDisabled,
  + //then ajax is disabled
  + var ajaxIsDisabled = false;
  + var ancestor = eventElement;
  + while (null != ancestor)

  Unknown macro: {+ if (toLowerCase(ancestor.tagName) == "form") { + break; + }+ if (isAjaxDisabled(formID, ancestor)) { + ajaxIsDisabled = true; + break; + }+ ancestor = ancestor.parentNode;+ }

  + if (ajaxIsDisabled) {
  //use native submit function saved by namespace.captureSubmit
  if (f && f.nativeSubmit) {
  var fakeClick = document.createElement("input");
  fakeClick.setAttribute("type", "hidden");

• fakeClick.setAttribute("name", element.name);
• fakeClick.setAttribute("value", element.value);
  + fakeClick.setAttribute("name", eventElement.name);
  + fakeClick.setAttribute("value", eventElement.value);
  f.appendChild(fakeClick);
  f.nativeSubmit();
  f.removeChild(fakeClick);

The above patch has been verified on commandLink with child elements on FireFox, IE7, and Chrome.

The changes to application.js expand the ability to capture the user event when the submit is captured (often due to form.submit() being invoked from commandLink handling, but also from automatic Ajax submit capture). Each different strategy is intended for a different browser: on Chrome, an "event" object was observed to be already in scope, on IE window.event is always available, and as a fallback (which actually works on most Netscape-offspring browsers but is the most fragile under jsf.js code changes) snag the event passed as a parameter to the onclick handler:

arguments.callee.caller.caller.arguments[0]

In submit.js, the additional details in the captured event are used to better find the ajaxDisabled state of the element: the algorithm searches upward (bailing out on a form or the top of the document) looking for ajaxDisabled. In other words, children of ajaxDisabled have ajax disabled.

Attaching modified files for use in trunk once code freeze completes.

covers testcases from testcases sheet

The following was tested successfully on IE7 and Chrome. Does it not cover the "Nok" cases described in Icefaces_7405.xlsx

<h:commandButton id="button1" value="Show/Hide" onclick="var x = 0;"
actionListener="#

">
<f:param name="llllllllllll" value="nnnnnnnnnnn" />
<f:ajax disabled="true" />
</h:commandLink>
<h:commandLink onclick="var x = 0;"
actionListener="#

">
<f:param name="llllllllllll" value="nnnnnnnnnnn" />
<f:ajax disabled="true" />
<span>
<h:outputText value="SpanShowHide"></h:outputText>
</span>
</h:commandLink>

Were errors observed in any browser, and was this test performed with the latest EE branch?

An improved fix has been checked in to the branch. This addresses some cases on FireFox, but does not yet address the case for IE with ajaxDisabled and no param.

Patrick, it may be difficult to handle all possible combinations of the attributes on all browsers, so please provide confirmation if there is now a strategy that works for you on the browsers you need to support.

Tyler, please provide a new build from the branch to the customer.

Additional code has been added that should handle IE behavior.

Passing along a note from Patrick:

Please find attached the test results based on the newest patch. Unfortunately IE8 is our target browser.

icefaces_7405_R2.xlsx

onclick="console.log();" will not work on IE; instead, use something like onclick="var x = 0;".

The recent merge with the trunk is causing a regression failure. Please see ICE-7454.

This fix is causing failures with various ACE components due to the following:

ice.ace.AjaxRequest = function(cfg) {

...

ice.fullSubmit(jsfExecute, jsfRender, null, source || form[0], function(parameter) {

The synthetic event passed by ice.ace.AjaxRequest is null.

This should be addressed, but will likely require extensive changes to where ice.ace.AjaxRequest is used. A sufficient fix to solve the regression will be to check for the null event when it occurs. The drawback will be that ice.ace.AjaxRequest cases will likely ignore ajax disabled.

A fix is checked in to proceed when the event is null.

This has been verified fixed in the reported cases. If specific cases are found where ajax disabled does not interact correctly with parameters, specific JIRAs can be created.