Details
Major Description
When f:ajax is used to initiate a request, and '@none' is the execution target, JSF spec indicates that the 'java.faces.partial.execute' request parameter should be left blank. This is also indicated by comments in MyFaces javascript and in the following issue:
https://issues.apache.org/jira/browse/MYFACES-2914
However, trace the same code where the behaviour is described in comments, and you'll find the following:
_transformList: function(passThrgh, target, srcStr, form, elementId) {
var _Lang = this._Lang;
//this is probably the fastest transformation method
//it uses an array and an index to position all elements correctly
//the offset variable is there to prevent 0 which results in a javascript
//false
var offset = 1,
vals = (srcStr) ? srcStr.split(/\s+/) : [],
idIdx = (vals.length) ? _Lang.arrToMap(vals, offset) : {},
//helpers to improve speed and compression
none = idIdx[this.IDENT_NONE],
all = idIdx[this.IDENT_ALL],
theThis = idIdx[this.IDENT_THIS],
theForm = idIdx[this.IDENT_FORM];
if (none)
{ //in case of none only one value is returned passThrgh[target] = this.IDENT_NONE; return passThrgh; }...
Which instead of setting a empty string for the 'javax.faces.partial.execute' request param, sets '@none' itself.
'@none' is submitted as the value of 'javax.faces.partial.execute', which causes the executing VisitTreeCallback to have the set of ids to execute ['@none', 'form3e:button']. 'form3e:button' is the value of 'javax.faces.source', and is the client id of the submitting element. This visit causes listeners and input on the submitting element to decode. This is erroneous behaviour for a request with '@none' as the sole target.
When using manual JavaScript debugging to prevent the offending '@none' request parameter, the request correctly did not execute the submitting element.
I will be attaching a proposed patch to resolve this issue as well as a reduced test case.