[jira] [Commented] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17859582#comment-17859582 ] Werner Punz commented on MYFACES-4672: -- https://github.com/apache/myfaces/pull/724 Pull request issued, [~volosied] can you please check if this fixes the issue in your customers use case scenario? If yes then we can upstream the fix as well to next if needed! > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856898#comment-17856898 ] Werner Punz edited comment on MYFACES-4672 at 6/22/24 7:10 PM: --- I am thinking about the following, I do not want to change the code extensively, given it is legacy code: if((targetBuf.has && targetBuf.has(identifier)) || (targetBuf.hasKey && targetBuf.hasKey(identifier))) you basically do a check first which type of targetBuf you have by checking the whether it has a has or hasKey and then proceed forward! Give this a shot! I will be able to provide a fix monday, but not earlier, sorry about that! But you can give it a try that way. was (Author: werpu): I am thinking about the following, I do not want to change the code big time if((targetBuf.has && targetBuf.has(identifier)) || (targetBuf.hasKey && targetBuf.hasKey(identifier))) you basically do a check first which type of targetBuf you have by checking the whether it has a has or hasKey and then proceed forward! Give this a shot! I will be able to provide a fix monday, but not earlier, sorry about that! But you can give it a try that way. > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856898#comment-17856898 ] Werner Punz edited comment on MYFACES-4672 at 6/22/24 12:36 PM: I am thinking about the following, I do not want to change the code big time if((targetBuf.has && targetBuf.has(identifier)) || (targetBuf.hasKey && targetBuf.hasKey(identifier))) you basically do a check first which type of targetBuf you have by checking the whether it has a has or hasKey and then proceed forward! Give this a shot! I will be able to provide a fix monday, but not earlier, sorry about that! But you can give it a try that way. was (Author: werpu): I am thinking about the following follliwing, I do not want to change the code big time if((targetBuf.has && targetBuf.has(identifier)) || (targetBuf.hasKey && targetBuf.hasKey(identifier))) you basically do a check first which type of targetBuf you have by checking the whether it has a has or hasKey and then proceed forward! Give this a shot! I will be able to provide a fix monday, but not earlier, sorry about that! But you can give it a try that way. > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856898#comment-17856898 ] Werner Punz commented on MYFACES-4672: -- I am thinking about the following follliwing, I do not want to change the code big time if((targetBuf.has && targetBuf.has(identifier)) || (targetBuf.hasKey && targetBuf.hasKey(identifier))) you basically do a check first which type of targetBuf you have by checking the whether it has a has or hasKey and then proceed forward! Give this a shot! I will be able to provide a fix monday, but not earlier, sorry about that! But you can give it a try that way. > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[
https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861
]
Werner Punz edited comment on MYFACES-4672 at 6/21/24 9:09 PM:
---
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the hasKey Function but the has function (seems this was
not fully specced out, when I coded this given that xhr2 was in beta at best
then, and they renamed it), we simply can identify the code parts which have
problems with the hasKey and use has instead as fallback, so if one or the
other is present we use either!
The reason why your patch fails is that createFormDataDecorator does not really
work with a real xhr level2 object! This was a fallback to work with iframe
transports but to keep the calls the same on the upper code levels!
So we need to fix this on the code parts which rely on the hasKey function
being present to also check for has!
This is a problem which probably the entire old codebase has!
As reference:
https://developer.mozilla.org/en-US/docs/Web/API/FormData/has?retiredLocale=de
was (Author: werpu):
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the hasKey Function but the has function (seems this was
not fully specced out, when I coded this given that xhr2 was in beta at best
then, and they renamed it), we simply can identify the code parts which have
problems with the hasKey and use has instead as fallback, so if one or the
other is present we use either!
The reason why your patch fails is that createFormDataDecorator does not really
work with a real xhr level2 object! This was a fallback to work with iframe
transports but to keep the calls the same on the upper code levels!
So we need to fix this on the code parts which rely on the hasKey function
being present to also check for has!
This is a problem which probably the entire old codebase has!
> Uncaught TypeError: G.hasKey is not a function
> --
>
> Key: MYFACES-4672
> URL: https://issues.apache.org/jira/browse/MYFACES-4672
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.16
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> This affects 2.2 which I know is out of date, but I have a user of MyFaces
> 2.2 who needs this bug fixed.
> I ported MYFACES-4606 to 2.2 here:
> [https://github.com/apache/myfaces/pull/647]
> 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't
> realize that _AjaxRequestLevel2 was removed from 2.3 in this PR:
> [https://github.com/apache/myfaces/pull/415/files]
> _AjaxRequestLevel2 still exists in the 2.2 codebase.
> This mean that `if(targetBuf.hasKey(identifier))` was called from
> _AjaxRequestLevel2's getFormData which does not decorate the FormData to
> include the hasKey method – thus we get " G.hasKey is not a function".
> [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44]
> This error is reproducible via multi-part form requests that use ajax.
> What is the proper fix here? I'll create a draft PR for what I think is
> correct.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[
https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861
]
Werner Punz edited comment on MYFACES-4672 at 6/21/24 9:08 PM:
---
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the hasKey Function but the has function (seems this was
not fully specced out, when I coded this given that xhr2 was in beta at best
then, and they renamed it), we simply can identify the code parts which have
problems with the hasKey and use has instead as fallback, so if one or the
other is present we use either!
The reason why your patch fails is that createFormDataDecorator does not really
work with a real xhr level2 object! This was a fallback to work with iframe
transports but to keep the calls the same on the upper code levels!
So we need to fix this on the code parts which rely on the hasKey function
being present to also check for has!
This is a problem which probably the entire old codebase has!
was (Author: werpu):
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the hasKey Function but the has function (seems this was
not fully specced out, when I coded this and they renamed it), we simply can
identify the code parts which have problems with the hasKey and use has instead
as fallback, so if one or the other is present we use either!
The reason why your patch fails is that createFormDataDecorator does not really
work with a real xhr level2 object! This was a fallback to work with iframe
transports but to keep the calls the same on the upper code levels!
So we need to fix this on the code parts which rely on the hasKey function
being present to also check for has!
This is a problem which probably the entire old codebase has!
> Uncaught TypeError: G.hasKey is not a function
> --
>
> Key: MYFACES-4672
> URL: https://issues.apache.org/jira/browse/MYFACES-4672
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.16
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> This affects 2.2 which I know is out of date, but I have a user of MyFaces
> 2.2 who needs this bug fixed.
> I ported MYFACES-4606 to 2.2 here:
> [https://github.com/apache/myfaces/pull/647]
> 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't
> realize that _AjaxRequestLevel2 was removed from 2.3 in this PR:
> [https://github.com/apache/myfaces/pull/415/files]
> _AjaxRequestLevel2 still exists in the 2.2 codebase.
> This mean that `if(targetBuf.hasKey(identifier))` was called from
> _AjaxRequestLevel2's getFormData which does not decorate the FormData to
> include the hasKey method – thus we get " G.hasKey is not a function".
> [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44]
> This error is reproducible via multi-part form requests that use ajax.
> What is the proper fix here? I'll create a draft PR for what I think is
> correct.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[
https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861
]
Werner Punz edited comment on MYFACES-4672 at 6/21/24 9:08 PM:
---
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the hasKey Function but the has function (seems this was
not fully specced out, when I coded this and they renamed it), we simply can
identify the code parts which have problems with the hasKey and use has instead
as fallback, so if one or the other is present we use either!
The reason why your patch fails is that createFormDataDecorator does not really
work with a real xhr level2 object! This was a fallback to work with iframe
transports but to keep the calls the same on the upper code levels!
So we need to fix this on the code parts which rely on the hasKey function
being present to also check for has!
This is a problem which probably the entire old codebase has!
was (Author: werpu):
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the hasKey Function but the has function (seems this was
not fully fixed when I coded this and they renamed it), we simply can identify
the code parts which have problems with the hasKey and use has instead as
fallback, so if one or the other is present we use either!
The reason why your patch fails is that createFormDataDecorator does not really
work with a real xhr level2 object! This was a fallback to work with iframe
transports but to keep the calls the same on the upper code levels!
So we need to fix this on the code parts which rely on the hasKey function
being present to also check for has!
This is a problem which probably the entire old codebase has!
> Uncaught TypeError: G.hasKey is not a function
> --
>
> Key: MYFACES-4672
> URL: https://issues.apache.org/jira/browse/MYFACES-4672
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.16
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> This affects 2.2 which I know is out of date, but I have a user of MyFaces
> 2.2 who needs this bug fixed.
> I ported MYFACES-4606 to 2.2 here:
> [https://github.com/apache/myfaces/pull/647]
> 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't
> realize that _AjaxRequestLevel2 was removed from 2.3 in this PR:
> [https://github.com/apache/myfaces/pull/415/files]
> _AjaxRequestLevel2 still exists in the 2.2 codebase.
> This mean that `if(targetBuf.hasKey(identifier))` was called from
> _AjaxRequestLevel2's getFormData which does not decorate the FormData to
> include the hasKey method – thus we get " G.hasKey is not a function".
> [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44]
> This error is reproducible via multi-part form requests that use ajax.
> What is the proper fix here? I'll create a draft PR for what I think is
> correct.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[
https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861
]
Werner Punz edited comment on MYFACES-4672 at 6/21/24 9:07 PM:
---
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the hasKey Function but the has function (seems this was
not fully fixed when I coded this and they renamed it), we simply can identify
the code parts which have problems with the hasKey and use has instead as
fallback, so if one or the other is present we use either!
The reason why your patch fails is that createFormDataDecorator does not really
work with a real xhr level2 object! This was a fallback to work with iframe
transports but to keep the calls the same on the upper code levels!
So we need to fix this on the code parts which rely on the hasKey function
being present to also check for has!
This is a problem which probably the entire old codebase has!
was (Author: werpu):
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the hasKey Function but the has function (seems this was
not fully fixed when I coded this and they renamed it), we simply can identify
the code parts which have problems with the hasKey and use has instead as
fallback, so if one or the other is present we use either!
> Uncaught TypeError: G.hasKey is not a function
> --
>
> Key: MYFACES-4672
> URL: https://issues.apache.org/jira/browse/MYFACES-4672
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.16
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> This affects 2.2 which I know is out of date, but I have a user of MyFaces
> 2.2 who needs this bug fixed.
> I ported MYFACES-4606 to 2.2 here:
> [https://github.com/apache/myfaces/pull/647]
> 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't
> realize that _AjaxRequestLevel2 was removed from 2.3 in this PR:
> [https://github.com/apache/myfaces/pull/415/files]
> _AjaxRequestLevel2 still exists in the 2.2 codebase.
> This mean that `if(targetBuf.hasKey(identifier))` was called from
> _AjaxRequestLevel2's getFormData which does not decorate the FormData to
> include the hasKey method – thus we get " G.hasKey is not a function".
> [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44]
> This error is reproducible via multi-part form requests that use ajax.
> What is the proper fix here? I'll create a draft PR for what I think is
> correct.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[
https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861
]
Werner Punz edited comment on MYFACES-4672 at 6/21/24 9:06 PM:
---
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the hasKey Function but the has function (seems this was
not fully fixed when I coded this and they renamed it), we simply can identify
the code parts which have problems with the hasKey and use has instead as
fallback, so if one or the other is present we use either!
was (Author: werpu):
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the getKey Function, we simply have to add a hasKey
function on the FormData class! This affects only the xhrLevel2 class, not the
newer ones and very likely also not the iframe transport itself!
> Uncaught TypeError: G.hasKey is not a function
> --
>
> Key: MYFACES-4672
> URL: https://issues.apache.org/jira/browse/MYFACES-4672
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.16
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> This affects 2.2 which I know is out of date, but I have a user of MyFaces
> 2.2 who needs this bug fixed.
> I ported MYFACES-4606 to 2.2 here:
> [https://github.com/apache/myfaces/pull/647]
> 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't
> realize that _AjaxRequestLevel2 was removed from 2.3 in this PR:
> [https://github.com/apache/myfaces/pull/415/files]
> _AjaxRequestLevel2 still exists in the 2.2 codebase.
> This mean that `if(targetBuf.hasKey(identifier))` was called from
> _AjaxRequestLevel2's getFormData which does not decorate the FormData to
> include the hasKey method – thus we get " G.hasKey is not a function".
> [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44]
> This error is reproducible via multi-part form requests that use ajax.
> What is the proper fix here? I'll create a draft PR for what I think is
> correct.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[
https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861
]
Werner Punz edited comment on MYFACES-4672 at 6/21/24 8:56 PM:
---
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the getKey Function, we simply have to add a hasKey
function on the FormData class! This affects only the xhrLevel2 class, not the
newer ones and very likely also not the iframe transport itself!
was (Author: werpu):
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the getKey Function, we simply have to add a hasKey
function on the FormData class!
> Uncaught TypeError: G.hasKey is not a function
> --
>
> Key: MYFACES-4672
> URL: https://issues.apache.org/jira/browse/MYFACES-4672
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.16
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> This affects 2.2 which I know is out of date, but I have a user of MyFaces
> 2.2 who needs this bug fixed.
> I ported MYFACES-4606 to 2.2 here:
> [https://github.com/apache/myfaces/pull/647]
> 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't
> realize that _AjaxRequestLevel2 was removed from 2.3 in this PR:
> [https://github.com/apache/myfaces/pull/415/files]
> _AjaxRequestLevel2 still exists in the 2.2 codebase.
> This mean that `if(targetBuf.hasKey(identifier))` was called from
> _AjaxRequestLevel2's getFormData which does not decorate the FormData to
> include the hasKey method – thus we get " G.hasKey is not a function".
> [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44]
> This error is reproducible via multi-part form requests that use ajax.
> What is the proper fix here? I'll create a draft PR for what I think is
> correct.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[
https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861
]
Werner Punz edited comment on MYFACES-4672 at 6/21/24 8:55 PM:
---
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the getKey Function, we simply have to add a hasKey
function on the FormData class!
was (Author: werpu):
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the getKey Function, we simply have to add a getKey
function on the FormData class!
> Uncaught TypeError: G.hasKey is not a function
> --
>
> Key: MYFACES-4672
> URL: https://issues.apache.org/jira/browse/MYFACES-4672
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.16
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> This affects 2.2 which I know is out of date, but I have a user of MyFaces
> 2.2 who needs this bug fixed.
> I ported MYFACES-4606 to 2.2 here:
> [https://github.com/apache/myfaces/pull/647]
> 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't
> realize that _AjaxRequestLevel2 was removed from 2.3 in this PR:
> [https://github.com/apache/myfaces/pull/415/files]
> _AjaxRequestLevel2 still exists in the 2.2 codebase.
> This mean that `if(targetBuf.hasKey(identifier))` was called from
> _AjaxRequestLevel2's getFormData which does not decorate the FormData to
> include the hasKey method – thus we get " G.hasKey is not a function".
> [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44]
> This error is reproducible via multi-part form requests that use ajax.
> What is the proper fix here? I'll create a draft PR for what I think is
> correct.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[
https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861
]
Werner Punz edited comment on MYFACES-4672 at 6/21/24 8:55 PM:
---
Ok the issue is very likely in the XHRRequestLevel2 code
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
ret = new FormData(this._sourceForm);
FormData does not have the getKey Function, we simply have to add a getKey
function on the FormData class!
was (Author: werpu):
I am a little bit puzzled why you get the g.hasKey is not a function. There is
decoration code which explicitly adds the hasKey
/**
* creates a neutral form data wrapper over an existing form Data element
* the wrapper delegates following methods, append
* and adds makeFinal as finalizing method which returns the final
* send representation of the element
*
* @param formData an array
*/
createFormDataDecorator:function (formData)
> Uncaught TypeError: G.hasKey is not a function
> --
>
> Key: MYFACES-4672
> URL: https://issues.apache.org/jira/browse/MYFACES-4672
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.16
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> This affects 2.2 which I know is out of date, but I have a user of MyFaces
> 2.2 who needs this bug fixed.
> I ported MYFACES-4606 to 2.2 here:
> [https://github.com/apache/myfaces/pull/647]
> 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't
> realize that _AjaxRequestLevel2 was removed from 2.3 in this PR:
> [https://github.com/apache/myfaces/pull/415/files]
> _AjaxRequestLevel2 still exists in the 2.2 codebase.
> This mean that `if(targetBuf.hasKey(identifier))` was called from
> _AjaxRequestLevel2's getFormData which does not decorate the FormData to
> include the hasKey method – thus we get " G.hasKey is not a function".
> [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44]
> This error is reproducible via multi-part form requests that use ajax.
> What is the proper fix here? I'll create a draft PR for what I think is
> correct.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861 ] Werner Punz edited comment on MYFACES-4672 at 6/21/24 8:53 PM: --- I am a little bit puzzled why you get the g.hasKey is not a function. There is decoration code which explicitly adds the hasKey /** * creates a neutral form data wrapper over an existing form Data element * the wrapper delegates following methods, append * and adds makeFinal as finalizing method which returns the final * send representation of the element * * @param formData an array */ createFormDataDecorator:function (formData) was (Author: werpu): I am a little bit puzzled why you get the g.hasKey is not a function. There is decoration code which explicitly adds the hasKey /** * creates a neutral form data wrapper over an existing form Data element * the wrapper delegates following methods, append * and adds makeFinal as finalizing method which returns the final * send representation of the element * * @param formData an array */ createFormDataDecorator:function (formData) That one creates formData shims and all of them have the hasKey, I will look into this! Btw. Multipart reverts in old browsers to an iframe transport if xhr level 2 cannot be provided > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861 ] Werner Punz edited comment on MYFACES-4672 at 6/21/24 8:53 PM: --- I am a little bit puzzled why you get the g.hasKey is not a function. There is decoration code which explicitly adds the hasKey /** * creates a neutral form data wrapper over an existing form Data element * the wrapper delegates following methods, append * and adds makeFinal as finalizing method which returns the final * send representation of the element * * @param formData an array */ createFormDataDecorator:function (formData) That one creates formData shims and all of them have the hasKey, I will look into this! Btw. Multipart reverts in old browsers to an iframe transport if xhr level 2 cannot be provided! * was (Author: werpu): I am a little bit puzzled why you get the g.hasKey is not a function. There is decoration code which explicitly adds the hasKey /** * creates a neutral form data wrapper over an existing form Data element * the wrapper delegates following methods, append * and adds makeFinal as finalizing method which returns the final * send representation of the element * * @param formData an array */ createFormDataDecorator:function (formData) That one creates formData shims and all of them have the hasKey, I will look into this! Btw. Multiform reverts in old browsers to an iframe transport! > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861 ] Werner Punz edited comment on MYFACES-4672 at 6/21/24 8:53 PM: --- I am a little bit puzzled why you get the g.hasKey is not a function. There is decoration code which explicitly adds the hasKey /** * creates a neutral form data wrapper over an existing form Data element * the wrapper delegates following methods, append * and adds makeFinal as finalizing method which returns the final * send representation of the element * * @param formData an array */ createFormDataDecorator:function (formData) That one creates formData shims and all of them have the hasKey, I will look into this! Btw. Multipart reverts in old browsers to an iframe transport if xhr level 2 cannot be provided was (Author: werpu): I am a little bit puzzled why you get the g.hasKey is not a function. There is decoration code which explicitly adds the hasKey /** * creates a neutral form data wrapper over an existing form Data element * the wrapper delegates following methods, append * and adds makeFinal as finalizing method which returns the final * send representation of the element * * @param formData an array */ createFormDataDecorator:function (formData) That one creates formData shims and all of them have the hasKey, I will look into this! Btw. Multipart reverts in old browsers to an iframe transport if xhr level 2 cannot be provided! * > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856861#comment-17856861 ] Werner Punz commented on MYFACES-4672: -- I am a little bit puzzled why you get the g.hasKey is not a function. There is decoration code which explicitly adds the hasKey /** * creates a neutral form data wrapper over an existing form Data element * the wrapper delegates following methods, append * and adds makeFinal as finalizing method which returns the final * send representation of the element * * @param formData an array */ createFormDataDecorator:function (formData) That one creates formData shims and all of them have the hasKey, I will look into this! Btw. Multiform reverts in old browsers to an iframe transport! > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4671) PushImpl.ts Socket#onerror attempting to use undefined variable
[
https://issues.apache.org/jira/browse/MYFACES-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-4671.
--
Resolution: Fixed
> PushImpl.ts Socket#onerror attempting to use undefined variable
> ---
>
> Key: MYFACES-4671
> URL: https://issues.apache.org/jira/browse/MYFACES-4671
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2, 4.1.0-RC2
> Environment: OS: Windows 11
> Java version 17.0.7
>Reporter: Thomas Smith
>Assignee: Werner Punz
>Priority: Minor
> Fix For: 5.0.0, 4.0.3, 4.1.0-RC3
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> While running some OpenLiberty FAT tests, specifically
> io.openliberty.org.apache.myfaces.4.0_fat/WebSocketTests, we discovered a
> small bug where JSON.parse(event.data) was running where event.data was
> undefined.
> Here is the line it occurs:
> [https://github.com/apache/myfaces/blob/dae36dde5cc42208d034dda23107ad79f68ecc3a/api/src/client/typescript/faces/impl/PushImpl.ts#L156]
> Volodymyr created a GitHub issue describing the issue here: [Faces 4.0 Fix
> WebSocketTests so that "onerror listener" occurs - Issue #27598 -
> OpenLiberty/open-liberty
> (github.com)|https://github.com/OpenLiberty/open-liberty/issues/27598]
> Proposed Solution: Change
> {code:java}
> JSON.parse(event.data) {code}
> to
> {code:java}
> JSON.parse(event.data === undefined ? null : event.data){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4671) PushImpl.ts Socket#onerror attempting to use undefined variable
[
https://issues.apache.org/jira/browse/MYFACES-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856859#comment-17856859
]
Werner Punz commented on MYFACES-4671:
--
I added the fix now to all 3 affected branches via the upstream project.
Also The fix is now the one with the Elvis operator usage!
> PushImpl.ts Socket#onerror attempting to use undefined variable
> ---
>
> Key: MYFACES-4671
> URL: https://issues.apache.org/jira/browse/MYFACES-4671
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2, 4.1.0-RC2
> Environment: OS: Windows 11
> Java version 17.0.7
>Reporter: Thomas Smith
>Assignee: Werner Punz
>Priority: Minor
> Fix For: 5.0.0, 4.0.3, 4.1.0-RC3
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> While running some OpenLiberty FAT tests, specifically
> io.openliberty.org.apache.myfaces.4.0_fat/WebSocketTests, we discovered a
> small bug where JSON.parse(event.data) was running where event.data was
> undefined.
> Here is the line it occurs:
> [https://github.com/apache/myfaces/blob/dae36dde5cc42208d034dda23107ad79f68ecc3a/api/src/client/typescript/faces/impl/PushImpl.ts#L156]
> Volodymyr created a GitHub issue describing the issue here: [Faces 4.0 Fix
> WebSocketTests so that "onerror listener" occurs - Issue #27598 -
> OpenLiberty/open-liberty
> (github.com)|https://github.com/OpenLiberty/open-liberty/issues/27598]
> Proposed Solution: Change
> {code:java}
> JSON.parse(event.data) {code}
> to
> {code:java}
> JSON.parse(event.data === undefined ? null : event.data){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4671) PushImpl.ts Socket#onerror attempting to use undefined variable
[
https://issues.apache.org/jira/browse/MYFACES-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856857#comment-17856857
]
Werner Punz commented on MYFACES-4671:
--
Btw the code can be written a little bit more tersely:
let message = JSON.parse(event?.data ?? null);
Typescript has an Elvis operator, so no need for explicity undefined checks
anymore!
I will prepare a new version of the upstream codebase then we can easily get
the new code into all branches!
> PushImpl.ts Socket#onerror attempting to use undefined variable
> ---
>
> Key: MYFACES-4671
> URL: https://issues.apache.org/jira/browse/MYFACES-4671
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2, 4.1.0-RC2
> Environment: OS: Windows 11
> Java version 17.0.7
>Reporter: Thomas Smith
>Assignee: Werner Punz
>Priority: Minor
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> While running some OpenLiberty FAT tests, specifically
> io.openliberty.org.apache.myfaces.4.0_fat/WebSocketTests, we discovered a
> small bug where JSON.parse(event.data) was running where event.data was
> undefined.
> Here is the line it occurs:
> [https://github.com/apache/myfaces/blob/dae36dde5cc42208d034dda23107ad79f68ecc3a/api/src/client/typescript/faces/impl/PushImpl.ts#L156]
> Volodymyr created a GitHub issue describing the issue here: [Faces 4.0 Fix
> WebSocketTests so that "onerror listener" occurs - Issue #27598 -
> OpenLiberty/open-liberty
> (github.com)|https://github.com/OpenLiberty/open-liberty/issues/27598]
> Proposed Solution: Change
> {code:java}
> JSON.parse(event.data) {code}
> to
> {code:java}
> JSON.parse(event.data === undefined ? null : event.data){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856854#comment-17856854 ] Werner Punz edited comment on MYFACES-4672 at 6/21/24 8:14 PM: --- I will look into it next week. As far as I remember, the old codebase built something similar as FormData to keep the code on the same level. I will look into it but wont make it before monday! The proper fix very likely simply is to add the function! was (Author: werpu): I will look into it next week. As far as I remember, the old codebase built something similar as FormData to keep the code on the same level. I will look into it but wont make it before monday! > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856854#comment-17856854 ] Werner Punz commented on MYFACES-4672: -- I will look into it next week. As far as I remember, the old codebase built something similar as FormData to keep the code on the same level. I will look into it but wont make it before monday! > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4671) PushImpl.ts Socket#onerror attempting to use undefined variable
[
https://issues.apache.org/jira/browse/MYFACES-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856124#comment-17856124
]
Werner Punz edited comment on MYFACES-4671 at 6/19/24 4:58 AM:
---
Looks fine to me as well!
I will merge it in asap and also will take the fix into the upstream project so
that it does not get lost!
Thanks for providing it!
was (Author: werpu):
Looks fine to me as well!
> PushImpl.ts Socket#onerror attempting to use undefined variable
> ---
>
> Key: MYFACES-4671
> URL: https://issues.apache.org/jira/browse/MYFACES-4671
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2, 4.1.0-RC2
> Environment: OS: Windows 11
> Java version 17.0.7
>Reporter: Thomas Smith
>Assignee: Werner Punz
>Priority: Minor
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> While running some OpenLiberty FAT tests, specifically
> io.openliberty.org.apache.myfaces.4.0_fat/WebSocketTests, we discovered a
> small bug where JSON.parse(event.data) was running where event.data was
> undefined.
> Here is the line it occurs:
> [https://github.com/apache/myfaces/blob/dae36dde5cc42208d034dda23107ad79f68ecc3a/api/src/client/typescript/faces/impl/PushImpl.ts#L156]
> Volodymyr created a GitHub issue describing the issue here: [Faces 4.0 Fix
> WebSocketTests so that "onerror listener" occurs - Issue #27598 -
> OpenLiberty/open-liberty
> (github.com)|https://github.com/OpenLiberty/open-liberty/issues/27598]
> Proposed Solution: Change
> {code:java}
> JSON.parse(event.data) {code}
> to
> {code:java}
> JSON.parse(event.data === undefined ? null : event.data){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4671) PushImpl.ts Socket#onerror attempting to use undefined variable
[
https://issues.apache.org/jira/browse/MYFACES-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856124#comment-17856124
]
Werner Punz commented on MYFACES-4671:
--
Looks fine to me as well!
> PushImpl.ts Socket#onerror attempting to use undefined variable
> ---
>
> Key: MYFACES-4671
> URL: https://issues.apache.org/jira/browse/MYFACES-4671
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2, 4.1.0-RC2
> Environment: OS: Windows 11
> Java version 17.0.7
>Reporter: Thomas Smith
>Assignee: Werner Punz
>Priority: Minor
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> While running some OpenLiberty FAT tests, specifically
> io.openliberty.org.apache.myfaces.4.0_fat/WebSocketTests, we discovered a
> small bug where JSON.parse(event.data) was running where event.data was
> undefined.
> Here is the line it occurs:
> [https://github.com/apache/myfaces/blob/dae36dde5cc42208d034dda23107ad79f68ecc3a/api/src/client/typescript/faces/impl/PushImpl.ts#L156]
> Volodymyr created a GitHub issue describing the issue here: [Faces 4.0 Fix
> WebSocketTests so that "onerror listener" occurs - Issue #27598 -
> OpenLiberty/open-liberty
> (github.com)|https://github.com/OpenLiberty/open-liberty/issues/27598]
> Proposed Solution: Change
> {code:java}
> JSON.parse(event.data) {code}
> to
> {code:java}
> JSON.parse(event.data === undefined ? null : event.data){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852460#comment-17852460
]
Werner Punz edited comment on MYFACES-4669 at 6/5/24 2:04 PM:
--
Yes Either the spec needs to change and we have to adapt or Mojarra needs to
fix it, lets wait for the result!
Btw. [~melloware], thanks for digging around, you saved me a few hours of work!
was (Author: werpu):
Yes Either the spec needs to change and we have to adapt or Mojarra needs to
fix it, lets wait for the result!
Btw. thanks for digging around, you saved me a few hours of work!
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852460#comment-17852460
]
Werner Punz commented on MYFACES-4669:
--
Yes Either the spec needs to change and we have to adapt or Mojarra needs to
fix it, lets wait for the result!
Btw. thanks for digging around, you saved me a few hours of work!
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-4669.
--
Resolution: Won't Fix
Seems to be a mojarra bug, the spec is clear on this one, no need to fix it on
the myfaces side then!
(See investigation from [~melloware] in the comments)
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852188#comment-17852188
]
Werner Punz edited comment on MYFACES-4669 at 6/4/24 8:43 PM:
--
I I just checked the comments on this one, wanted to take over it on thursday,
if it is a Mojarra bug then yes it needs to be filed on the mojarra side not on
the MyFaces side. MyFaces seems to follow the spec here, Mojarra not!
I will unassign me from this bug then, feel free to close it!
was (Author: werpu):
I I just checked the comments on this one, wanted to take over it on thursday,
if it is a mojarra bug then yes it needs to be filed on the mojarra side not on
the myfaces side. MyFaces seems to follow the spec here, Mojarra not!
I will unassign me from this bug then, feel free to close it!
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852188#comment-17852188
]
Werner Punz commented on MYFACES-4669:
--
I I just checked the comments on this one, wanted to take over it on thursday,
if it is a mojarra bug then yes it needs to be filed on the mojarra side not on
the myfaces side. MyFaces seems to follow the spec here, Mojarra not!
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852188#comment-17852188
]
Werner Punz edited comment on MYFACES-4669 at 6/4/24 8:42 PM:
--
I I just checked the comments on this one, wanted to take over it on thursday,
if it is a mojarra bug then yes it needs to be filed on the mojarra side not on
the myfaces side. MyFaces seems to follow the spec here, Mojarra not!
I will unassign me from this bug then, feel free to close it!
was (Author: werpu):
I I just checked the comments on this one, wanted to take over it on thursday,
if it is a mojarra bug then yes it needs to be filed on the mojarra side not on
the myfaces side. MyFaces seems to follow the spec here, Mojarra not!
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4670) [Invalid] Cannot Uncheck CheckBox (MYFACES-4606 Regression)
[
https://issues.apache.org/jira/browse/MYFACES-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852162#comment-17852162
]
Werner Punz commented on MYFACES-4670:
--
Great thanks for the update, as for the other issue assigned to me, I will
start to work on it on thursday, wont have time before!
> [Invalid] Cannot Uncheck CheckBox (MYFACES-4606 Regression)
>
>
> Key: MYFACES-4670
> URL: https://issues.apache.org/jira/browse/MYFACES-4670
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Volodymyr Siedlecki
>Priority: Minor
> Attachments: checkbox.war
>
>
> You cannot uncheck a checkbox after it is selected. App is attached. It
> looks like a regression from MYFACES-4606. MyFaces 3.0/2.3 look fine and only
> 4.0 seems to be affected here.
> Form Data is found below:
> Working (3.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Second >>>
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Failing (4.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"{code}
> Second >
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1:box "true"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850259#comment-17850259
]
Werner Punz edited comment on MYFACES-4669 at 5/29/24 5:44 AM:
---
I will have a look the next few days, lets see what I can find out!
Have assigned it temporarily to me, so that it does not get lost on me!
was (Author: werpu):
I will have a look the next few days, lets see what I can find out!
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850259#comment-17850259
]
Werner Punz commented on MYFACES-4669:
--
I will have a look the next few days, lets see what I can find out!
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\;>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
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: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)
