[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[
https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844679#comment-17844679
]
Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:45 PM:
--
Does not really matter, see my updated comment, the question is what the
resource id field itself is which gets updated, if it is a script tag then it
automatically gets evaled, but then the eval section is pointless, on the other
hand if you have the eval section you wont need the embedded script doing the
same.
This is a "garbage" response!
Btw forgot, the modern eval method for scripts is to append them to the head
and clear them out again, that way the browser safely can do the eval!
All 3 implementations of the scripts nowadays use this method for evaling js!
Might play into this, but this is just a sidenote!
{code:java}
// code placeholder
globalEval(code: string, nonce ?: string): DomQuery {
const head = document.getElementsByTagName("head")?.[0]
?? document.documentElement.getElementsByTagName("head")?.[0];
const script = document.createElement("script");
if (nonce) {
if ('undefined' != typeof script?.nonce) {
script.nonce = nonce;
} else {
script.setAttribute("nonce", nonce);
}
}
script.type = "text/javascript";
script.innerHTML = code;
let newScriptElement = head.appendChild(script);
head.removeChild(newScriptElement);
return this;
} {code}
What happens here is at the moment the script is appended it gets evaled by the
browser engine, and once evaled it is removed...
was (Author: werpu):
Does not really matter, see my updated comment, the question is what the
resource id field itself is which gets updated, if it is a script tag then it
automatically gets evaled, but then the eval section is pointless, on the other
hand if you have the eval section you wont need the embedded script doing the
same.
This is a "garbage" response!
Btw forgot, the modern eval method for scripts is to append them to the head
and clear them out again, that way the browser safely can do the eval!
All 3 implementations of the scripts nowadays use this method for evaling js!
Might play into this, but this is just a sidenote!
> onloadScript not rendering with non ajax command button if jstl type tag c:if
> is present on the page
>
>
> Key: MYFACES-4378
> URL: https://issues.apache.org/jira/browse/MYFACES-4378
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>Priority: Minor
> Attachments: pf-11780.zip, test.7z
>
>
> See https://github.com/omnifaces/omnifaces/issues/366
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844679#comment-17844679 ] Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:43 PM: -- Does not really matter, see my updated comment, the question is what the resource id field itself is which gets updated, if it is a script tag then it automatically gets evaled, but then the eval section is pointless, on the other hand if you have the eval section you wont need the embedded script doing the same. This is a "garbage" response! Btw forgot, the modern eval method for scripts is to append them to the head and clear them out again, that way the browser safely can do the eval! All 3 implementations of the scripts nowadays use this method for evaling js! Might play into this, but this is just a sidenote! was (Author: werpu): Does not really matter, see my updated comment, the question is what the resource id field itself is which gets updated, if it is a script tag then it automatically gets evaled, but then the eval section is pointless, on the other hand if you have the eval section you wont need the embedded script doing the same. This is a "garbage" response! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844679#comment-17844679 ] Werner Punz commented on MYFACES-4378: -- Does not really matter, see my updated comment, the question is what the resource id field itself is which gets updated, if it is a script tag then it automatically gets evaled, but then the eval section is pointless, on the other hand if you have the eval section you wont need the embedded script doing the same. This is a "garbage" response! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844671#comment-17844671 ] Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:39 PM: -- I just checked our scripts, there is no dedicated handling of a javax.faces.Resource field... If there is one, it would only get executed/evaled automatically if it is of type script type="text/javascript" in this case the eval would not be needed, in the second case if there is an eval, then a script type="text/javascript" id="javax.faces.Resource" is pointless and you would get a double eval, but the culprit here is a renderer sending such a response! the namespace javax.faces.Resource normally is for resource requests not render areas, but using it is not a spec violation to my knowledge, any id on a script would have produced the same result! was (Author: werpu): yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... Either way, it is either or not both... you will get a double execution this way! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844671#comment-17844671 ] Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:32 PM: -- yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... Either way, it is either or not both... you will get a double execution this way! was (Author: werpu): yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844671#comment-17844671 ] Werner Punz commented on MYFACES-4378: -- yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843571#comment-17843571 ] Werner Punz edited comment on MYFACES-4378 at 5/5/24 2:33 PM: -- Well, I dont think the new typescript based myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and provides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! was (Author: werpu): Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and provides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843571#comment-17843571 ] Werner Punz edited comment on MYFACES-4378 at 5/5/24 2:32 PM: -- Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and provides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! was (Author: werpu): Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and prov ides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843571#comment-17843571 ] Werner Punz commented on MYFACES-4378: -- Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and prov ides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-4658.
--
Fix Version/s: 5.0.0
4.1.0-RC2
4.0.3
Resolution: Fixed
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833954#comment-17833954
]
Werner Punz commented on MYFACES-4658:
--
[~volosied] I have fixed the issue in the 3 attached pull requests (each for
each branch which uses the new codebase) please give it a shot, and if it works
for you then I can merge!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:15 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
Should be an easy fix, expect it later today!
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret ===
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:14 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
{{}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ?
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:09 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
{{}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:08 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz commented on MYFACES-4658:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833668#comment-17833668
]
Werner Punz commented on MYFACES-4658:
--
Yes I will take care of it. I need to compare this with the spec as well!
Probably a slight deviation from the spec I have introduced here with my
rewrite!
Should be easy to fix!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789435#comment-17789435
]
Werner Punz commented on MYFACES-4606:
--
Yes, sorry to answer so late, has been resolved this week!
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4640) Smaller issues with the appendIussingElements code discovered by Tobago Tests
[ https://issues.apache.org/jira/browse/MYFACES-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4640. -- Fix Version/s: 4.0.2 4.1.0 5.0.0 Resolution: Fixed Resolved by merge of the latest codebase from jsf_ts! > Smaller issues with the appendIussingElements code discovered by Tobago Tests > - > > Key: MYFACES-4640 > URL: https://issues.apache.org/jira/browse/MYFACES-4640 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.0, 4.0.1, 5.0.0 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > Fix For: 4.0.2, 4.1.0, 5.0.0 > > > The Tobago people have discovered several smaller issues regards the new > appendIssuingItem code where the item was incorrectly added or with a wrong > value. > This is fixed now and fortified with unit tests testing the scenarii! > Tobago runs now with jsf.js_next_gen@4.0.2-beta.8 so I will move this version > back into myfaces! > The fixes from tobago already have pending pull requests for 3.0 and 2.3-next -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4640) Smaller issues with the appendIussingElements code discovered by Tobag Usecases
Werner Punz created MYFACES-4640: Summary: Smaller issues with the appendIussingElements code discovered by Tobag Usecases Key: MYFACES-4640 URL: https://issues.apache.org/jira/browse/MYFACES-4640 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.0.1, 4.0.0, 5.0.0 Reporter: Werner Punz The Tobago people have discovered several smaller issues regards the new appendIssuingItem code where the item was incorrectly added or with a wrong value. This is fixed now and fortified with unit tests testing the scenarii! Tobago runs now with jsf.js_next_gen@4.0.2-beta.8 so I will move this version back into myfaces! The fixes from tobago already have pending pull requests for 3.0 and 2.3-next -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-4638.
--
Resolution: Fixed
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784108#comment-17784108
]
Werner Punz commented on MYFACES-4638:
--
Fixed
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784088#comment-17784088
]
Werner Punz commented on MYFACES-4638:
--
Seems like the fix is not entirely complete I am getting a cut off part after
the & in my unit test, I need to debug this out!
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784083#comment-17784083
]
Werner Punz edited comment on MYFACES-4638 at 11/8/23 2:54 PM:
---
Patch works, my existing tests pass, but I want to add a dedicated test for
this exact usecase in my unit tests!
So be patient, I will issue a merge request later today for 4 +
PS: Thanks for debugging this out, it was really helpful!
was (Author: werpu):
Patch works, my existing tests pass, but I want to add a dedicated test for
this exact usecase in my unit tests!
So be patient, I will issue a merge request later today for 4 +
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784083#comment-17784083
]
Werner Punz commented on MYFACES-4638:
--
Patch works, my existing tests pass, but I want to add a dedicated test for
this exact usecase in my unit tests!
So be patient, I will issue a merge request later today for 4 +
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783992#comment-17783992
]
Werner Punz commented on MYFACES-4638:
--
Thanks I will take over this!
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782508#comment-17782508
]
Werner Punz commented on MYFACES-4636:
--
No I dont think so, but we have to double check this!
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Fix For: 3.0.3, 4.0.2, 2.3-next-M9, 4.1.0, 5.0.0
>
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> // function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782455#comment-17782455
]
Werner Punz edited comment on MYFACES-4636 at 11/3/23 8:18 AM:
---
Looks ok to me, the test reconfirms the result anyway, I wonder why the +colon
was added, probably a misunderstanding of the mechanism, but we will see!
This might not only affect 2.3 but also the other branches, this needs to be
reconfirmed!
Thanks for fixing this [~tandraschko]
was (Author: werpu):
Looks ok to me, the test reconfirms the result anyway, I wonder why the +colon
was added, probably a misunderstanding of the mechanism, but we will see!
Thanks for fixing this [~tandraschko]
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Fix For: 4.0.2, 2.3-next-M9, 4.1.0, 5.0.0
>
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> // function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782455#comment-17782455
]
Werner Punz commented on MYFACES-4636:
--
Looks ok to me, the test reconfirms the result anyway, I wonder why the +colon
was added, probably a misunderstanding of the mechanism, but we will see!
Thanks for fixing this [~tandraschko]
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Fix For: 4.0.2, 2.3-next-M9, 4.1.0, 5.0.0
>
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> // function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781339#comment-17781339
]
Werner Punz edited comment on MYFACES-4636 at 10/31/23 12:52 PM:
-
This seems to be an issue in the java renderer, the analysis is correct, the
chain function is wrongly constructed!
a comma is missing after testJs! Afair when I did the 4.0 javascripts I noticed
that the spec passing the params has changed slightly, i adapted the code, you
now can and should pass params maps via params: instead of just
passing the map!
I left the way how we did it in the past open, but it seems there was a slight
mistake in the changes in the java renderer adapting to the spec conform api!
was (Author: werpu):
This seems to be an issue in the java renderer, the analysis is correct, the
chain function is wrongly constructed!
a comma is missing after testJs!
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> // function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781339#comment-17781339
]
Werner Punz edited comment on MYFACES-4636 at 10/31/23 12:50 PM:
-
This seems to be an issue in the java renderer, the analysis is correct, the
chain function is wrongly constructed!
a comma is missing after testJs!
was (Author: werpu):
This seems to be an issue in the java renderer, the analysis is correct, the
chain function is wrongly constructed!
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> // function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781339#comment-17781339
]
Werner Punz edited comment on MYFACES-4636 at 10/31/23 12:49 PM:
-
This seems to be an issue in the java renderer, the analysis is correct, the
chain function is wrongly constructed!
was (Author: werpu):
This seems to be an issue in the java renderer, this is not syntatically
correct, onevent wants a function. There seems to be something going wrong with
the params rendering onEvent: testJsParams is definitely wrong here!
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> // function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781339#comment-17781339
]
Werner Punz commented on MYFACES-4636:
--
This seems to be an issue in the java renderer, this is not syntatically
correct, onevent wants a function. There seems to be something going wrong with
the params rendering onEvent: testJsParams is definitely wrong here!
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> // function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17775044#comment-17775044
]
Werner Punz commented on MYFACES-4606:
--
Pull request opened [https://github.com/apache/myfaces/pull/630]
you can check it, I will merge on monday, unless someone else wants to do it!
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774670#comment-17774670
]
Werner Punz commented on MYFACES-4606:
--
Ok I checked the old code, the old code does not have this problem because only
buttons and submits are appended (we might add hrefs in the long run if
requested)
So I can roll a new jsf_ts release tomorrow and pull the changes in.
The fix is more or less that I basically do not append a checkbox or radio
button as issuing element if it is unchecked (hence the value is not appended
then)
Since the mechanism is needed mostly for buttons anyway (and hrefs), it should
be ok to have this behavior!
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774160#comment-17774160
]
Werner Punz commented on MYFACES-4606:
--
I have it working for the new codebase, the old one I have not had time to fix
it, will be done by end of the week!
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (TOBAGO-2250) Ajax request adds a new meta tag
[
https://issues.apache.org/jira/browse/TOBAGO-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772509#comment-17772509
]
Werner Punz edited comment on TOBAGO-2250 at 10/6/23 10:03 AM:
---
Ah ok, thanks for the clarification.
Yes this is then definitely an issue with the jsf.js codebase!
I need to check the update code, we have something in the update head to deal
with this, I guess we need to apply the same algorithm, did not have it on the
radar that meta tags also can be in update resource!
was (Author: werpu):
Ah ok, thanks for the clarification.
Yes this is then definitely an issue with the jsf.js codebase!
> Ajax request adds a new meta tag
>
>
> Key: TOBAGO-2250
> URL: https://issues.apache.org/jira/browse/TOBAGO-2250
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 6.0.0-beta-1
>Reporter: Henning Nöth
>Assignee: Henning Nöth
>Priority: Critical
>
> With every ajax request, a
> {code:xml}
>
> {code}
> tag is added to .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TOBAGO-2250) Ajax request adds a new meta tag
[
https://issues.apache.org/jira/browse/TOBAGO-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772509#comment-17772509
]
Werner Punz commented on TOBAGO-2250:
-
Ah ok, thanks for the clarification.
Yes this is then definitely an issue with the jsf.js codebase!
> Ajax request adds a new meta tag
>
>
> Key: TOBAGO-2250
> URL: https://issues.apache.org/jira/browse/TOBAGO-2250
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 6.0.0-beta-1
>Reporter: Henning Nöth
>Assignee: Henning Nöth
>Priority: Critical
>
> With every ajax request, a
> {code:xml}
>
> {code}
> tag is added to .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TOBAGO-2250) Ajax request adds a new meta tag
[
https://issues.apache.org/jira/browse/TOBAGO-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772502#comment-17772502
]
Werner Punz commented on TOBAGO-2250:
-
jsf.js_next_gen does not really add any meta tags, but I can check my js code,
this is more likely on the java side.
> Ajax request adds a new meta tag
>
>
> Key: TOBAGO-2250
> URL: https://issues.apache.org/jira/browse/TOBAGO-2250
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 6.0.0-beta-1
>Reporter: Henning Nöth
>Assignee: Henning Nöth
>Priority: Critical
>
> With every ajax request, a
> {code:xml}
>
> {code}
> tag is added to .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz reopened MYFACES-4606:
--
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772292#comment-17772292
]
Werner Punz edited comment on MYFACES-4606 at 10/5/23 4:33 PM:
---
Working on it, only checkboxes and radio buttons are affected by this problem.
I will need to roll another small jsf_ts bugfix script for it, the fix is
minor, I just check the type and exclude the appendIssuingItem in this case.
Given that the behavior is needed for links or buttons only anyway, I can live
with this small inconsistency!
Also the old branches need to be checked. So expect the final fix for all
affected branches next week!
was (Author: werpu):
Working on it, only checkboxes and radio buttons are affected by this problem.
I will need to roll another small jsf_ts bugfix script for it, the fix is
minor, I just check the type and exclude the appendIssuingItem in this case.
Given that the behavior is needed for links or buttons only anyway, I can live
with this small inconsistency!
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772292#comment-17772292
]
Werner Punz commented on MYFACES-4606:
--
Working on it, only checkboxes and radio buttons are affected by this problem.
I will need to roll another small jsf_ts bugfix script for it, the fix is
minor, I just check the type and exclude the appendIssuingItem in this case.
Given that the behavior is needed for links or buttons only anyway, I can live
with this small inconsistency!
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4630. -- Fix Version/s: 4.0.2 Resolution: Fixed merge pull request form [~volosied] > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > Fix For: 4.0.2 > > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771338#comment-17771338 ] Werner Punz edited comment on MYFACES-4630 at 10/3/23 12:42 PM: No they are more a goody than anything else, you do not necessarily need them, they might save a little bit of bandwith though (not that important but it was a low hanging fruit), you can turn the build off in the webpack file by taking out the plugins which produce them! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work (aka wont show the typscript sources during debugging instead of the js sources)! I would not recommend to turn them off for the development version, having a working debugging possibility which shows the typescripts is a must! was (Author: werpu): No they are more a goody than anything else, you do not necessarily need them, they might save a little bit of bandwith though (not that important but it was a low hanging fruit), you can turn the build off in the node file! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work (aka wont show the typscript sources during debugging instead of the js sources)! I would not recommend to turn them off for the development version, having a working debugging possibility which shows the typescripts is a must! > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771458#comment-17771458
]
Werner Punz edited comment on MYFACES-4536 at 10/3/23 12:21 PM:
Ok I will alter my test accordingly, lets see!
Still passing:
[https://gist.github.com/werpu/93e05f0cba260be33349afec8564c9d9]
Is producing:
{code:java}
{code}
So no swallowed eval! So, neither the partial response writer nor the
HTMLResponseWriterImpl produce this problem (those are the ones which are in
the chain)
was (Author: werpu):
Ok I will alter my test accordingly, lets see!
Still passing:
[https://gist.github.com/werpu/93e05f0cba260be33349afec8564c9d9]
Is producing:
{code:java}
{code}
So no swallowed eval!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, image-2023-10-02-20-33-05-162.png,
> mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771458#comment-17771458
]
Werner Punz edited comment on MYFACES-4536 at 10/3/23 12:18 PM:
Ok I will alter my test accordingly, lets see!
Still passing:
[https://gist.github.com/werpu/93e05f0cba260be33349afec8564c9d9]
Is producing:
{code:java}
{code}
So no swallowed eval!
was (Author: werpu):
Ok I will alter my test accordingly, lets see!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, image-2023-10-02-20-33-05-162.png,
> mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771458#comment-17771458
]
Werner Punz commented on MYFACES-4536:
--
Ok I will alter my test accordingly, lets see!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, image-2023-10-02-20-33-05-162.png,
> mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771338#comment-17771338 ] Werner Punz edited comment on MYFACES-4630 at 10/3/23 5:39 AM: --- No they are more a goody than anything else, you do not necessarily need them, they might save a little bit of bandwith though (not that important but it was a low hanging fruit), you can turn the build off in the node file! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work (aka wont show the typscript sources during debugging instead of the js sources)! I would not recommend to turn them off for the development version, having a working debugging possibility which shows the typescripts is a must! was (Author: werpu): No they are more a goody than anything else, you do not necessarily need them, they might save a little bit of bandwith though (not that important but it was a low hanging fruit), you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work (aka wont show the typscript sources during debugging instead of the js sources)! I would not recommend to turn them off for the development version, having a working debugging possibility which shows the typescripts is a must! > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771338#comment-17771338 ] Werner Punz edited comment on MYFACES-4630 at 10/3/23 5:38 AM: --- No they are more a goody than anything else, you do not necessarily need them, they might save a little bit of bandwith though (not that important but it was a low hanging fruit), you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work (aka wont show the typscript sources during debugging instead of the js sources)! I would not recommend to turn them off for the development version, having a working debugging possibility which shows the typescripts is a must! was (Author: werpu): No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work! > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771339#comment-17771339
]
Werner Punz edited comment on MYFACES-4536 at 10/3/23 5:36 AM:
---
[~melloware] could you make it work, if not then I have to look into the other
responsewriters, to find which one is responsible to cause such a behavior in
the chain!
was (Author: werpu):
[~melloware] could you make it work, if not then I have to look into the other
responsewriters, to find which one is at culprit here!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, image-2023-10-02-20-33-05-162.png,
> mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771339#comment-17771339
]
Werner Punz commented on MYFACES-4536:
--
[~melloware] could you make it work, if not then I have to look into the other
responsewriters, to find which one is at culprit here?
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, image-2023-10-02-20-33-05-162.png,
> mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771339#comment-17771339
]
Werner Punz edited comment on MYFACES-4536 at 10/3/23 5:35 AM:
---
[~melloware] could you make it work, if not then I have to look into the other
responsewriters, to find which one is at culprit here!
was (Author: werpu):
[~melloware] could you make it work, if not then I have to look into the other
responsewriters, to find which one is at culprit here?
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, image-2023-10-02-20-33-05-162.png,
> mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771338#comment-17771338 ] Werner Punz edited comment on MYFACES-4630 at 10/3/23 5:34 AM: --- No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work! was (Author: werpu): No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771338#comment-17771338 ] Werner Punz edited comment on MYFACES-4630 at 10/3/23 5:33 AM: --- No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? was (Author: werpu): No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771338#comment-17771338 ] Werner Punz commented on MYFACES-4630: -- No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771244#comment-17771244
]
Werner Punz edited comment on MYFACES-4606 at 10/2/23 6:45 PM:
---
Will look at this. We probably simply cannot attach a key value pair for
elements exposing this behavior, to my knowledge only checkboxes and radio
buttons should be affected by this, because they can hold values but expose the
values only by their respective state.
The internal code check does not test for type but only if a value is present,
however in case of a checkbox or radio button the flag checked is the
overriding flag here.
was (Author: werpu):
Will look at this.
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771244#comment-17771244
]
Werner Punz commented on MYFACES-4606:
--
Will look at this.
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771243#comment-17771243
]
Werner Punz edited comment on MYFACES-4536 at 10/2/23 6:33 PM:
---
The behavior itself works:
[https://gist.github.com/werpu/3d3fdeaa8e75336f7aa5b63bd480b04c]
This test passes, so yes, the problem is not in the writer itself or the
partial response writer, so yes the csp response writer might be the culprit
here or another one in the chain:
!image-2023-10-02-20-33-05-162.png|width=435,height=72!
was (Author: werpu):
The behavior itself works:
[https://gist.github.com/werpu/3d3fdeaa8e75336f7aa5b63bd480b04c]
This test passes, so yes, the problem is not in the writer itself or the
partial response writer:
!image-2023-10-02-20-33-05-162.png|width=435,height=72!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, image-2023-10-02-20-33-05-162.png,
> mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771243#comment-17771243
]
Werner Punz commented on MYFACES-4536:
--
The behavior itself works:
[https://gist.github.com/werpu/3d3fdeaa8e75336f7aa5b63bd480b04c]
This test passes, so yes, the problem is not in the writer itself or the
partial response writer:
!image-2023-10-02-20-33-05-162.png|width=435,height=72!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, image-2023-10-02-20-33-05-162.png,
> mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771238#comment-17771238
]
Werner Punz edited comment on MYFACES-4536 at 10/2/23 6:21 PM:
---
I think the main difference really is the wrapped here, let me try a test!
was (Author: werpu):
In my opinion the problem lies more on the way the response writer chain is
constructed, the way the writers are generated is that they are passed down and
cloned.
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771238#comment-17771238
]
Werner Punz commented on MYFACES-4536:
--
In my opinion the problem lies more on the way the response writer chain is
constructed, the way the writers are generated is that they are passed down and
cloned.
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165 ] Werner Punz edited comment on MYFACES-4536 at 10/2/23 4:28 PM: --- Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like //With following code: _writer.startDocument(); _writer.startElement("eval", null); _writer.startCDATA(); _writer.write("if(window.PrimeFaces){PrimeFaces.csp.init('NjcwMDg5ZDgtYmEwZi00NDAzLWI3Y2MtZTk1OTY4Y2VjNzY2');};;PrimeFaces.csp.register('j_id_7k:j_id_7l:globalFilter','onchange',function(event){PF('customersTable').filter()});PrimeFaces.csp.register('j_id_7k:j_id_7l:j_id_7o','onclick',function(event){PrimeFaces.ab({s:\"j_id_7k:j_id_7l:j_id_7o\",f:\"j_id_7k\",u:\"@form\"});return false;});;"); _writer.endCDATA(); _writer.endElement("eval"); _writer.endDocument();{code} So the response writer behaves correctly if called directly in myfaces. (just for the protocol), I will try to replicate the primefaces case next! Still not sure what the problem is, I cannot see it in the code itself either at writer level. was (Author: werpu): Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like // With following code: _writer.startDocument(); _writer.startElement("eval", null); _writer.startCDATA(); _writer.write("if(window.PrimeFaces){PrimeFaces.csp.init('NjcwMDg5ZDgtYmEwZi00NDAzLWI3Y2MtZTk1OTY4Y2VjNzY2');};;PrimeFaces.csp.register('j_id_7k:j_id_7l:globalFilter','onchange',function(event){PF('customersTable').filter()});PrimeFaces.csp.register('j_id_7k:j_id_7l:j_id_7o','onclick',function(event){PrimeFaces.ab({s:\"j_id_7k:j_id_7l:j_id_7o\",f:\"j_id_7k\",u:\"@form\"});return false;});;"); _writer.endCDATA(); _writer.endElement("eval"); _writer.endDocument();{code} So the response writer behaves correctly if called directly in myfaces. (just for the protocol), I will try to replicate the primefaces case next! Still not sure what the problem is, I cannot see it in the
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165 ] Werner Punz edited comment on MYFACES-4536 at 10/2/23 4:24 PM: --- Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like //{code} So the response writer behaves correctly if called directly in myfaces. (just for the protocol), I will try to replicate the primefaces case next! Still not sure what the problem is, I cannot see it in the code itself either at writer level. was (Author: werpu): Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like // {code} So the response writer behaves correctly if called directly in myfaces. > PartialResponseWriter: Do no wrap the writer > > > Key: MYFACES-4536 > URL: https://issues.apache.org/jira/browse/MYFACES-4536 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2 >Reporter: Melloware >Assignee: Werner Punz >Priority: Major > Attachments: csp-results.zip, mojarra-csp-new.txt > > > Per BalusC: > Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been > deprecated in order to force implementors to instead use the constructor > taking the wrapped instance (and to raise their awareness), so that logically > the inherited {{getWrapped()}} method will be used throughout the > implementation instead of the local {{wrapped}} variable. This will ensure > that the correct implementation is returned and correct behavior is performed > might the {{FacesWrapper}} implementation itself being wrapped by yet another > {{FacesWrapper}} implementation further down the chain. Because, when the > {{FacesWrapper}}
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165 ] Werner Punz edited comment on MYFACES-4536 at 10/2/23 4:24 PM: --- Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like //With following code: _writer.startDocument(); _writer.startElement("eval", null); _writer.startCDATA(); _writer.write("if(window.PrimeFaces){PrimeFaces.csp.init('NjcwMDg5ZDgtYmEwZi00NDAzLWI3Y2MtZTk1OTY4Y2VjNzY2');};;PrimeFaces.csp.register('j_id_7k:j_id_7l:globalFilter','onchange',function(event){PF('customersTable').filter()});PrimeFaces.csp.register('j_id_7k:j_id_7l:j_id_7o','onclick',function(event){PrimeFaces.ab({s:\"j_id_7k:j_id_7l:j_id_7o\",f:\"j_id_7k\",u:\"@form\"});return false;});;"); _writer.endCDATA(); _writer.endElement("eval"); _writer.endDocument();{code} So the response writer behaves correctly if called directly in myfaces. (just for the protocol), I will try to replicate the primefaces case next! Still not sure what the problem is, I cannot see it in the code itself either at writer level. was (Author: werpu): Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like // {code} So the response writer behaves correctly if called directly in myfaces. (just for the protocol), I will try to replicate the primefaces case next! Still not sure what the problem is, I cannot see it in the code itself either at writer level. > PartialResponseWriter: Do no wrap the writer > > > Key: MYFACES-4536 > URL: https://issues.apache.org/jira/browse/MYFACES-4536 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2 >Reporter: Melloware >Assignee: Werner Punz >
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165 ] Werner Punz edited comment on MYFACES-4536 at 10/2/23 4:22 PM: --- Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like //{code} So the response writer behaves correctly if called directly in myfaces. was (Author: werpu): Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like // PartialResponseWriter: Do no wrap the writer > > > Key: MYFACES-4536 > URL: https://issues.apache.org/jira/browse/MYFACES-4536 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2 >Reporter: Melloware >Assignee: Werner Punz >Priority: Major > Attachments: csp-results.zip, mojarra-csp-new.txt > > > Per BalusC: > Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been > deprecated in order to force implementors to instead use the constructor > taking the wrapped instance (and to raise their awareness), so that logically > the inherited {{getWrapped()}} method will be used throughout the > implementation instead of the local {{wrapped}} variable. This will ensure > that the correct implementation is returned and correct behavior is performed > might the {{FacesWrapper}} implementation itself being wrapped by yet another > {{FacesWrapper}} implementation further down the chain. Because, when the > {{FacesWrapper}} implementation incorrectly/accidentally uses the local > {{wrapped}} variable instead of the {{getWrapped()}} method, then that other > {{FacesWrapper}} implementation will basically be completely ignored, hereby > breaking the decorator pattern. > > PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165 ] Werner Punz edited comment on MYFACES-4536 at 10/2/23 3:47 PM: --- Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like // // PartialResponseWriter: Do no wrap the writer > > > Key: MYFACES-4536 > URL: https://issues.apache.org/jira/browse/MYFACES-4536 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2 >Reporter: Melloware >Assignee: Werner Punz >Priority: Major > Attachments: csp-results.zip, mojarra-csp-new.txt > > > Per BalusC: > Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been > deprecated in order to force implementors to instead use the constructor > taking the wrapped instance (and to raise their awareness), so that logically > the inherited {{getWrapped()}} method will be used throughout the > implementation instead of the local {{wrapped}} variable. This will ensure > that the correct implementation is returned and correct behavior is performed > might the {{FacesWrapper}} implementation itself being wrapped by yet another > {{FacesWrapper}} implementation further down the chain. Because, when the > {{FacesWrapper}} implementation incorrectly/accidentally uses the local > {{wrapped}} variable instead of the {{getWrapped()}} method, then that other > {{FacesWrapper}} implementation will basically be completely ignored, hereby > breaking the decorator pattern. > > PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165 ] Werner Punz edited comment on MYFACES-4536 at 10/2/23 3:40 PM: --- Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like // // PartialResponseWriter: Do no wrap the writer > > > Key: MYFACES-4536 > URL: https://issues.apache.org/jira/browse/MYFACES-4536 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2 >Reporter: Melloware >Assignee: Werner Punz >Priority: Major > Attachments: csp-results.zip, mojarra-csp-new.txt > > > Per BalusC: > Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been > deprecated in order to force implementors to instead use the constructor > taking the wrapped instance (and to raise their awareness), so that logically > the inherited {{getWrapped()}} method will be used throughout the > implementation instead of the local {{wrapped}} variable. This will ensure > that the correct implementation is returned and correct behavior is performed > might the {{FacesWrapper}} implementation itself being wrapped by yet another > {{FacesWrapper}} implementation further down the chain. Because, when the > {{FacesWrapper}} implementation incorrectly/accidentally uses the local > {{wrapped}} variable instead of the {{getWrapped()}} method, then that other > {{FacesWrapper}} implementation will basically be completely ignored, hereby > breaking the decorator pattern. > > PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165 ] Werner Punz edited comment on MYFACES-4536 at 10/2/23 3:40 PM: --- Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like // // PartialResponseWriter: Do no wrap the writer > > > Key: MYFACES-4536 > URL: https://issues.apache.org/jira/browse/MYFACES-4536 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2 >Reporter: Melloware >Assignee: Werner Punz >Priority: Major > Attachments: csp-results.zip, mojarra-csp-new.txt > > > Per BalusC: > Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been > deprecated in order to force implementors to instead use the constructor > taking the wrapped instance (and to raise their awareness), so that logically > the inherited {{getWrapped()}} method will be used throughout the > implementation instead of the local {{wrapped}} variable. This will ensure > that the correct implementation is returned and correct behavior is performed > might the {{FacesWrapper}} implementation itself being wrapped by yet another > {{FacesWrapper}} implementation further down the chain. Because, when the > {{FacesWrapper}} implementation incorrectly/accidentally uses the local > {{wrapped}} variable instead of the {{getWrapped()}} method, then that other > {{FacesWrapper}} implementation will basically be completely ignored, hereby > breaking the decorator pattern. > > PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165 ] Werner Punz edited comment on MYFACES-4536 at 10/2/23 3:39 PM: --- Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I wrote it, that embedded code can have cdata like // PartialResponseWriter: Do no wrap the writer > > > Key: MYFACES-4536 > URL: https://issues.apache.org/jira/browse/MYFACES-4536 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2 >Reporter: Melloware >Assignee: Werner Punz >Priority: Major > Attachments: csp-results.zip, mojarra-csp-new.txt > > > Per BalusC: > Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been > deprecated in order to force implementors to instead use the constructor > taking the wrapped instance (and to raise their awareness), so that logically > the inherited {{getWrapped()}} method will be used throughout the > implementation instead of the local {{wrapped}} variable. This will ensure > that the correct implementation is returned and correct behavior is performed > might the {{FacesWrapper}} implementation itself being wrapped by yet another > {{FacesWrapper}} implementation further down the chain. Because, when the > {{FacesWrapper}} implementation incorrectly/accidentally uses the local > {{wrapped}} variable instead of the {{getWrapped()}} method, then that other > {{FacesWrapper}} implementation will basically be completely ignored, hereby > breaking the decorator pattern. > > PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771165#comment-17771165
]
Werner Punz edited comment on MYFACES-4536 at 10/2/23 3:31 PM:
---
Hi I have started to look into it now, its been a while since I looked into it,
but the problem maybe related to the xml filter
public PartialResponseWriterImpl(ResponseWriter writer)
{ super(writer.cloneWithWriter(new IllegalXmlCharacterFilterWriter(writer))); }
Which in itself fixes another issue which myfaces had with illegal characters.
I will post info when I know more of the real cause.
As for the double buffering response writer, I think it has to do with the
problem that if you embed cdata into cdata you have the "escape" it by
splitting it into several cdata sections.
Hence this probably was done this way. But all of this atm is just guessing! I
will debug this out tonight! To get a better idea what is happening!
was (Author: werpu):
Hi I have started to look into it now, its been a while since I looked into it,
but the problem maybe related to the xml filter
public PartialResponseWriterImpl(ResponseWriter writer)
{
super(writer.cloneWithWriter(new IllegalXmlCharacterFilterWriter(writer)));
}
Which in itself fixes another issue which myfaces had with illegal characters.
I will post info when I know more of the real cause.
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771165#comment-17771165
]
Werner Punz commented on MYFACES-4536:
--
Hi I have started to look into it now, its been a while since I looked into it,
but the problem maybe related to the xml filter
public PartialResponseWriterImpl(ResponseWriter writer)
{
super(writer.cloneWithWriter(new IllegalXmlCharacterFilterWriter(writer)));
}
Which in itself fixes another issue which myfaces had with illegal characters.
I will post info when I know more of the real cause.
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770196#comment-17770196
]
Werner Punz commented on MYFACES-4536:
--
Thanks I will tackle this now asap, sorry for the delay, I was bound by private
life and projects. I guess I will find time to start to work on it at the
weekend!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756573#comment-17756573 ] Werner Punz edited comment on MYFACES-4536 at 8/20/23 7:38 PM: --- Ok... the double buffering was there for only one reason, if you have a CDATA element with some embedded CDATA in (AKA hosting another CDATA element for instance in some embedded html like update etc...) it runs another encoding step to get this out. This is valid behavior in a sense that html code can embed javascript (there is an internal parsing step on the client side to cover this case) And a valid usecase to define a script block is
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756573#comment-17756573 ] Werner Punz edited comment on MYFACES-4536 at 8/20/23 7:38 PM: --- Ok... the double buffering was there for only one reason, if you have a CDATA element with some embedded CDATA in (AKA hosting another CDATA element for instance in some embedded html like update etc...) it runs another encoding step to get this out aka
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756573#comment-17756573 ] Werner Punz edited comment on MYFACES-4536 at 8/20/23 7:38 PM: --- Ok... the double buffering was there for only one reason, if you have a CDATA element with some embedded CDATA in (AKA hosting another CDATA element for instance in some embedded html like update etc...) it runs another encoding step to get this out aka
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756573#comment-17756573 ] Werner Punz commented on MYFACES-4536: -- Ok... the double buffering was there for only one reason, if you have a CDATA element with some embedded CDATA in (AKA hosting another CDATA element for instance in some embedded html like update etc...) it runs another encoding step to get this out aka
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753335#comment-17753335
]
Werner Punz commented on MYFACES-4536:
--
I will have a look at this bug, the next few days. Might take a few days since
atm I only can work on myfaces in my sparetime, but I have it on my radar now!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753332#comment-17753332
]
Werner Punz edited comment on MYFACES-4536 at 8/11/23 7:45 PM:
---
This is indeed a bug in myfaces, the response eval section is perfectly valid
within the spec!
It definitely should not be gone!
Good question where this happens, it basically can only happen within the
response writer!
I do not remember why the double buffering was added, this was a long time ago.
But it should not make a difference! So if it happens there it definitely is a
bug.
was (Author: werpu):
This is indeed a bug in myfaces, the response eval section is perfectly valid
within the spec!
It definitely should not be gone!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753332#comment-17753332
]
Werner Punz commented on MYFACES-4536:
--
This is indeed a bug in myfaces, the response eval section is perfectly valid
within the spec!
It definitely should not be gone!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[ https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4605. -- Fix Version/s: 4.0.2 Resolution: Fixed 4.0.2 added because it fixes the identifier issue, that was the only thing which was incorrect on the client side, and the rest is not an error per se, but how the system behaves! > Cross form rending via ajax, form is missing ViewState > -- > > Key: MYFACES-4605 > URL: https://issues.apache.org/jira/browse/MYFACES-4605 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.1, 2.3.10 >Reporter: Joe Crichton >Assignee: Werner Punz >Priority: Major > Fix For: 2.3.11, 3.0.3, 4.0.2 > > Attachments: image-2023-06-20-21-22-50-593.png > > > Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as > discussed here > [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),] > and [https://github.com/jakartaee/faces/issues/790] > Using openliberty with jsf-3.0 feature still has this occurring. Using the > workaround outlined by the first link fixes the issue. I believe the same is > true for the jsf-2.3 feature as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4610. -- Fix Version/s: 4.0.2 4.0.0 Resolution: Fixed > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > Fix For: 4.0.2, 4.0.0 > > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740879#comment-17740879 ] Werner Punz edited comment on MYFACES-4610 at 7/7/23 5:32 AM: -- The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently ) was (Author: werpu): The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently) > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740879#comment-17740879 ] Werner Punz edited comment on MYFACES-4610 at 7/7/23 5:32 AM: -- The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently https://issues.apache.org/jira/browse/MYFACES-4606) was (Author: werpu): The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently ) > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740879#comment-17740879 ] Werner Punz edited comment on MYFACES-4610 at 7/7/23 5:32 AM: -- The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently https://issues.apache.org/jira/browse/MYFACES-4605) was (Author: werpu): The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently https://issues.apache.org/jira/browse/MYFACES-4606) > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740879#comment-17740879 ] Werner Punz commented on MYFACES-4610: -- The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently) > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737968#comment-17737968 ] Werner Punz commented on MYFACES-4610: -- Pull request merged for main (Myfaces 4.0), other branches will follow the upcoming days > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[ https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737814#comment-17737814 ] Werner Punz commented on MYFACES-4605: -- Have issued a fix for the id :0 problem for myfaces 4.0 which will be merged today. Will issue a fix for the 2.x and 3.x branches later this week! > Cross form rending via ajax, form is missing ViewState > -- > > Key: MYFACES-4605 > URL: https://issues.apache.org/jira/browse/MYFACES-4605 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.1, 2.3.10 >Reporter: Joe Crichton >Assignee: Werner Punz >Priority: Major > Fix For: 2.3.11, 3.0.3 > > Attachments: image-2023-06-20-21-22-50-593.png > > > Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as > discussed here > [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),] > and [https://github.com/jakartaee/faces/issues/790] > Using openliberty with jsf-3.0 feature still has this occurring. Using the > workaround outlined by the first link fixes the issue. I believe the same is > true for the jsf-2.3 feature as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737813#comment-17737813 ] Werner Punz commented on MYFACES-4610: -- have issued a pull request which soon will be merged, will issue fixes for the 2.x branches in the upcoming days! > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737688#comment-17737688 ] Werner Punz edited comment on MYFACES-4610 at 6/27/23 3:19 PM: --- The issue here is indeed the fix we added recently that a key value pair of the issuing element is added. The problem here is that the issuing element has the same id (the virtual element tobago-select-many-checkbox but has no value, to make matters worse the embedded real inputs have the same name as the input elements id: Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737688#comment-17737688 ] Werner Punz edited comment on MYFACES-4610 at 6/27/23 2:32 PM: --- The issue here is indeed the fix we added recently that a key value pair of the issuing element is added. The problem here is that the issuing element has the same id (the virtual element tobago-select-many-checkbox but has no value, to make matters worse the embedded real inputs have the same name as the input elements id: Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737688#comment-17737688 ] Werner Punz commented on MYFACES-4610: -- The issue here is indeed the fix we added recently that a key value pair of the issuing element is added. The problem here is that the issuing element has the same id (the virtual element tobago-select-many-checkbox but has no value, to make matters worse the embedded real inputs have the same name as the input elements id: Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737019#comment-17737019 ] Werner Punz commented on MYFACES-4610: -- I also will add the fix discussed in MYFACES-4605 for starting the id with a counter of 1 in the fix for this issue, to avoid too many commits! > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install 4. cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
Werner Punz created MYFACES-4610: Summary: Fix for issuing element key:value combination breaks Tobago Key: MYFACES-4610 URL: https://issues.apache.org/jira/browse/MYFACES-4610 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.3-next-M8, 3.0.2, 4.0.2 Reporter: Werner Punz [https://github.com/henningn/myfaces-tobago.git] 4 checkboxes on the page, example does not work anymore because * git checkout jsfjs_next_gen402 * mvn clean install 4. cd tobago-example/tobago-example-demo * mvn clean -Pdev -Pjetty jetty:run * open [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] The request adds the issuing element with a null value! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[ https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736367#comment-17736367 ] Werner Punz edited comment on MYFACES-4605 at 6/23/23 6:53 AM: --- Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! PS: Another possible solution would be to include the viewstate nevertheless in the form response that way the Viewstate in the update tag would only update the embedded ViewState. But that would need a small server side fix someone else has to perform. From the js code perspective, it makes no difference a) No Viewstate element, the element is added at the last processing step b) Viewstate element present in the form, only the value is updated with the one coming in from the tag, then also the id would not change compared to the embedded one. These are the two cases which must be supported as per spec, afair. I am not entirely sure how Mojarra behaves for this case, I guess we should be in sync with their response xml patterns here! was (Author: werpu): Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) PS: Another possible solution would be to include the viewstate nevertheless in the form response that way the viewstate in the viestate update tag would only update the embedded viewstate. But that would need a small server side fix someone else has to perform. From the js code it makes no difference a) No Viewstate element, the element is added at the last processing step b) Viewstate element present in the form, only the value is updated with the one coming in from the tag, then also the id would not change compared to the embedded one. If you want to implement this option then we have 2 viewstate definitions in the response but also the advantage of server side id control! Either option is fine the 0->1 fix must be added anyway, the other option wont break the js code! I am not entirely sure how Mojarra behaves for this case, I guess we should be in sync with their response pattern here! > Cross form rending via ajax, form is missing ViewState > -- > > Key: MYFACES-4605 > URL: https://issues.apache.org/jira/browse/MYFACES-4605 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.1, 2.3.10 >Reporter: Joe Crichton >Assignee: Werner Punz >Priority: Major > Fix For: 2.3.11, 3.0.3 > > Attachments: image-2023-06-20-21-22-50-593.png > > > Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as > discussed here > [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),] > and [https://github.com/jakartaee/faces/issues/790] > Using openliberty with jsf-3.0 feature still has this occurring. Using the > workaround outlined by the first link fixes the issue. I believe the same is > true for the jsf-2.3 feature as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[ https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736367#comment-17736367 ] Werner Punz edited comment on MYFACES-4605 at 6/23/23 6:51 AM: --- Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) PS: Another possible solution would be to include the viewstate nevertheless in the form response that way the viewstate in the viestate update tag would only update the embedded viewstate. But that would need a small server side fix someone else has to perform. From the js code it makes no difference a) No Viewstate element, the element is added at the last processing step b) Viewstate element present in the form, only the value is updated with the one coming in from the tag, then also the id would not change compared to the embedded one. If you want to implement this option then we have 2 viewstate definitions in the response but also the advantage of server side id control! Either option is fine the 0->1 fix must be added anyway, the other option wont break the js code! I am not entirely sure how Mojarra behaves for this case, I guess we should be in sync with their response pattern here! was (Author: werpu): Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) PS: Another possible solution would be to include the viewstate nevertheless in the form response that way the viewstate in the viestate update tag would only update the embedded viewstate. But that would need a small server side fix someone else has to perform. From the js code it makes no difference a) No Viewstate element, the element is added at the last processing step b) Viewstate element present in the form, only the value is updated with the one coming in from the tag, then also the id would not change compared to the embedded one. If you want to implement this option then we have 2 viewstate definitions in the response but also the advantage of server side id control! Either option is fine the 0->1 fix must be added anyway, the other option wont break the js code! > Cross form rending via ajax, form is missing ViewState > -- > > Key: MYFACES-4605 > URL: https://issues.apache.org/jira/browse/MYFACES-4605 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.1, 2.3.10 >Reporter: Joe Crichton >Assignee: Werner Punz >Priority: Major > Fix For: 2.3.11, 3.0.3 > > Attachments: image-2023-06-20-21-22-50-593.png > > > Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as > discussed here > [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),] > and [https://github.com/jakartaee/faces/issues/790] > Using openliberty with jsf-3.0 feature still has this occurring. Using the > workaround outlined by the first link fixes the issue. I believe the same is > true for the jsf-2.3 feature as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[ https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736367#comment-17736367 ] Werner Punz edited comment on MYFACES-4605 at 6/23/23 6:49 AM: --- Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) PS: Another possible solution would be to include the viewstate nevertheless in the form response that way the viewstate in the viestate update tag would only update the embedded viewstate. But that would need a small server side fix someone else has to perform. From the js code it makes no difference a) No Viewstate element, the element is added at the last processing step b) Viewstate element present in the form, only the value is updated with the one coming in from the tag, then also the id would not change compared to the embedded one. If you want to implement this option then we have 2 viewstate definitions in the response but also the advantage of server side id control! Either option is fine the 0->1 fix must be added anyway, the other option wont break the js code! was (Author: werpu): Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) > Cross form rending via ajax, form is missing ViewState > -- > > Key: MYFACES-4605 > URL: https://issues.apache.org/jira/browse/MYFACES-4605 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.1, 2.3.10 >Reporter: Joe Crichton >Assignee: Werner Punz >Priority: Major > Fix For: 2.3.11, 3.0.3 > > Attachments: image-2023-06-20-21-22-50-593.png > > > Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as > discussed here > [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),] > and [https://github.com/jakartaee/faces/issues/790] > Using openliberty with jsf-3.0 feature still has this occurring. Using the > workaround outlined by the first link fixes the issue. I believe the same is > true for the jsf-2.3 feature as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[ https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736367#comment-17736367 ] Werner Punz commented on MYFACES-4605: -- Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) > Cross form rending via ajax, form is missing ViewState > -- > > Key: MYFACES-4605 > URL: https://issues.apache.org/jira/browse/MYFACES-4605 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.1, 2.3.10 >Reporter: Joe Crichton >Assignee: Werner Punz >Priority: Major > Fix For: 2.3.11, 3.0.3 > > Attachments: image-2023-06-20-21-22-50-593.png > > > Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as > discussed here > [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),] > and [https://github.com/jakartaee/faces/issues/790] > Using openliberty with jsf-3.0 feature still has this occurring. Using the > workaround outlined by the first link fixes the issue. I believe the same is > true for the jsf-2.3 feature as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[ https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735872#comment-17735872 ] Werner Punz commented on MYFACES-4605: -- Ok now I have gotten it, this is a server side "issue", I was only looking on my part, the ajax code. The behavior is not incorrect per se, but might not be ideal for some cases, better for others. First of all the view state is not embedded but it is handled as its own response tag. This is allowed by the spec, in a multiform case the executing form and the form containing the rendered elements get updated viewstates. To handle this is basically that you pass the viewstate as separate response tag and let the client resolve this in the javascript code. Theoretically you also could render the viewstate in the form in the response, but you need to pass it separately anyway because also the issuing form needs to be updated. I guess myfaces simply has skipped this to avoid double view state definitions in the reponse. Again I don´t think this is a bug, because the post processing must be done anyway, you wont lose any performance. Second: The reason why the id changes is simply following: The id is not important except for some internal processing, but must be unique, at submit the jakarta.faces.ViewState name is passed as key. But the id must be set and must include the viewroot identifier, the number at the end is just basically an incrementing number so that the id is unique in the entire page. Again the spec leaves it open what you do with this number in the end, the end result must be simply a unique id! Either way, in the end you will have a proper consistent state after rendering with the viewstates being updated in both forms, but if you look into the response you might not have the viewstates embedded in the form. Again I think this is correct behavior! Someone else might chime in and correct me on this. > Cross form rending via ajax, form is missing ViewState > -- > > Key: MYFACES-4605 > URL: https://issues.apache.org/jira/browse/MYFACES-4605 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.1, 2.3.10 >Reporter: Joe Crichton >Assignee: Werner Punz >Priority: Major > Fix For: 2.3.11, 3.0.3 > > Attachments: image-2023-06-20-21-22-50-593.png > > > Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as > discussed here > [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),] > and [https://github.com/jakartaee/faces/issues/790] > Using openliberty with jsf-3.0 feature still has this occurring. Using the > workaround outlined by the first link fixes the issue. I believe the same is > true for the jsf-2.3 feature as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[
https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735435#comment-17735435
]
Werner Punz edited comment on MYFACES-4605 at 6/21/23 2:01 PM:
---
Mhh I tried it in my integration testsuite by altering my multiform test:
{code:java}
// code placeholder
{code}
The test runs 100 times an alternative click either click1 or click2
and then processes the ajax response:
!image-2023-06-20-21-22-50-593.png|width=661,height=159!
In the end I am getting a properly updated viewstate which is identical on both
forms.
The behavor looks correct to me! I also walked through the code, the viewstate
of the executing form is updated as well as the viewstate of the forms in the
render area.
This is correct behavior, as per spec!
Testcase was run against
MyFaces 3.0.3-SNAPSHOT
Can you give me a concrete example where your code fails?
As far as I can see the behavior is correct according to the spec (even takes
the viewroot id into consideration in the code), but I might have missed
something here.
was (Author: werpu):
Mhh I tried it in my integration testsuite by altering my multiform test:
{code:java}
// code placeholder
{code}
The test runs 100 times an alternative click either click1 or click2
and then processes the ajax response:
!image-2023-06-20-21-22-50-593.png|width=661,height=159!
In the end I am getting a properly updated viewstate which is identical on both
forms.
The behavor looks correct to me! I also walked through the code, the viewstate
of the executing form is updated as well as the viewstate of the forms in the
render area.
This is correct behavior, as per spec!
Testcase was run against
MyFaces 3.0.3-SNAPSHOT
Can you give me a concrete example where your code fails?
As far as I can see the behavior is correct according to the spec (even takes
the viewroot id into consideration in the code), but I might have missed
something here.
> Cross form rending via ajax, form is missing ViewState
> --
>
> Key: MYFACES-4605
> URL: https://issues.apache.org/jira/browse/MYFACES-4605
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 3.0.1, 2.3.10
>Reporter: Joe Crichton
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3
>
> Attachments: image-2023-06-20-21-22-50-593.png
>
>
> Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as
> discussed here
> [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),]
> and [https://github.com/jakartaee/faces/issues/790]
> Using openliberty with jsf-3.0 feature still has this occurring. Using the
> workaround outlined by the first link fixes the issue. I believe the same is
> true for the jsf-2.3 feature as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[
https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735435#comment-17735435
]
Werner Punz edited comment on MYFACES-4605 at 6/20/23 8:00 PM:
---
Mhh I tried it in my integration testsuite by altering my multiform test:
{code:java}
// code placeholder
{code}
The test runs 100 times an alternative click either click1 or click2
and then processes the ajax response:
!image-2023-06-20-21-22-50-593.png|width=661,height=159!
In the end I am getting a properly updated viewstate which is identical on both
forms.
The behavor looks correct to me! I also walked through the code, the viewstate
of the executing form is updated as well as the viewstate of the forms in the
render area.
This is correct behavior, as per spec!
Testcase was run against
MyFaces 3.0.3-SNAPSHOT
Can you give me a concrete example where your code fails?
As far as I can see the behavior is correct according to the spec (even takes
the viewroot id into consideration in the code), but I might have missed
something here.
was (Author: werpu):
Mhh I tried it in my integration testsuite by altering my multiform test:
{code:java}
// code placeholder
{code}
The test runs 100 times an alternative click either click1 or click2
and then processes the ajax response:
!image-2023-06-20-21-22-50-593.png|width=661,height=159!
In the end I am getting a properly updated viewstate which is identical on both
forms.
Testcase was run against
MyFaces 3.0.3-SNAPSHOT
Can you give me a concrete example where your code fails?
As far as I can see the behavior is correct according to the spec (even takes
the viewroot id into consideration in the code), but I might have missed
something here.
The behavor looks correct to me! I also walked through the code, the viewstate
of the executing form is updated as well as the viewstate of the forms in the
render area.
This is correct behavior, as per spec!
> Cross form rending via ajax, form is missing ViewState
> --
>
> Key: MYFACES-4605
> URL: https://issues.apache.org/jira/browse/MYFACES-4605
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 3.0.1, 2.3.10
>Reporter: Joe Crichton
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3
>
> Attachments: image-2023-06-20-21-22-50-593.png
>
>
> Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as
> discussed here
> [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),]
> and [https://github.com/jakartaee/faces/issues/790]
> Using openliberty with jsf-3.0 feature still has this occurring. Using the
> workaround outlined by the first link fixes the issue. I believe the same is
> true for the jsf-2.3 feature as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
