It's not clear what the behaviour in this case should be, other than obviously not blowing up with JS errors. I'd guess that the next f:ajax tag should be ignored since the submit is not being triggered within the h:inputText component?

I just tested the fix with their app. It does look to have resolved the JS
error. I am seeing one side effect, when the submit occurs they have some
code to show a processing popup, following the same steps I don't see this
popup displaying but the table row is updated. This is called through the
onclick event of the menu item. Looking at the logs the call is made, but
the popup doesn't get displayed.

Arran

When deciding to invoke onBeforeUpdate listeners assume a user initiated submit when the form source element is undefined.

A popup message is shown only when the triggered event handler invokes showProcessingMessage(msg) function. The 'onclick' event handler of the 'Print' tab does not call showProcessingMessage(), hence no popup shown.

Just tested on the Williams application the latest trunk code. It looks like its broken again. The following JS error is thrown when trying to submit the row:

element is null
return toLowerCase(element...' ? element : enclosingForm(element);

Clicking on the error it is related to the follwing bridge.js (line 65) code:

function formOf(element)

Further testing shows that if the nested f:ajax tag does not actually render, things continue to work (<f:ajax execute="@this" render="@none "/> ).

The onclick handler of the "print" button is as follows:

onclick="this.id = 'sub_Screen1:screen1Form:printTab'; (function() { ice.ace.ab(

);; })(

);"

The element ID should not be modified after the element is created, and especially not during event processing.

The menu component must be modified to not use the illegal JavaScript technique. The modification of the id during event handling results in null "source" values during event processing.

It might be possible to add error checking code to abort processing when the event source is null, but this would have unpredictable side effects.

It may be possible to use a hidden field specific to this component and not use the element with the changing ID at all (for instance, make the "source" be the root of the menu). This is similar to how h:commandLink is implemented.

This issue was fixed by avoiding setting the id to the element and then calling ice.ace.AjaxRequest. Instead, a node reference is provided to ice.ace.AjaxRequest and the id of the element will be set there, inside the function. The passed node reference will be used in the underlying submit functions. One more measure was taken to avoid conflicts with other ajax requests on the page. It consists of triggering the menu action with a delay via the setTimeout() function.