[jira] [Resolved] (TOBAGO-2358) Updating JDK for runtime and build time
[ https://issues.apache.org/jira/browse/TOBAGO-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-2358. - Resolution: Fixed > Updating JDK for runtime and build time > --- > > Key: TOBAGO-2358 > URL: https://issues.apache.org/jira/browse/TOBAGO-2358 > Project: MyFaces Tobago > Issue Type: Task > Components: Build >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Major > Fix For: 2.6.0, 4.7.0, 5.14.0, 6.6.0 > > > The *minimum* JDK requirements in the active branches are outdated and need > to be updated > ||Branch / Version||Runtime JDK old||Runtime JDK new||Build Time JDK > old||Build Time JDK new|| > |Tobago 6|8|17|11|17| > |Tobago 5|8|17|8|17| > |Tobago 4|8|8|8|17| > |Tobago 2|7|8|8|17| > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2356) Replace animal-sniffer-plugin with Java compiler option "--release"
[ https://issues.apache.org/jira/browse/TOBAGO-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-2356. - Resolution: Fixed > Replace animal-sniffer-plugin with Java compiler option "--release" > --- > > Key: TOBAGO-2356 > URL: https://issues.apache.org/jira/browse/TOBAGO-2356 > Project: MyFaces Tobago > Issue Type: Task > Components: Build >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Minor > Fix For: 2.6.0, 4.7.0, 5.14.0, 6.6.0 > > > The animal-sniffer-plugin has only support until JDK 8. > With Java 9 comes a new compiler option -release (also replacing -source and > -target) to check also the JDK dependencies of the code, to avoid using > future features of the JDK when using a newer compiler. > BTW: > There is also an unlucky variable name used: > * maven.compile.source instead of maven.compiler.source > * maven.compile.target instead of maven.compiler.target > The latter configuring the maven-compiler-plugin automatically. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2346) File upload: There are warning logs when there is a non required empty tag
[ https://issues.apache.org/jira/browse/TOBAGO-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-2346. - Fix Version/s: 5.14.0 6.6.0 Resolution: Fixed > File upload: There are warning logs when there is a non required empty > tag > > > Key: TOBAGO-2346 > URL: https://issues.apache.org/jira/browse/TOBAGO-2346 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.13.0, 6.5.0 >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Trivial > Fix For: 5.14.0, 6.6.0 > > > If the filename is blank, there is a warning. > Should not be logged, when there is no content. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2353) File upload client validation
[ https://issues.apache.org/jira/browse/TOBAGO-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-2353. - Resolution: Fixed > File upload client validation > - > > Key: TOBAGO-2353 > URL: https://issues.apache.org/jira/browse/TOBAGO-2353 > Project: MyFaces Tobago > Issue Type: Improvement >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Major > Fix For: 5.14.0, 6.6.0 > > > A client site validation will check the size and show an alert, if the size > is too large. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Siedlecki resolved MYFACES-4666.
--
Assignee: Volodymyr Siedlecki
Resolution: Fixed
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Trivial
> Fix For: 5.0.0, 4.1.0-RC3
>
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4678) Getting NPE FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)
[
https://issues.apache.org/jira/browse/MYFACES-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886631#comment-17886631
]
Vladimir Dvorak commented on MYFACES-4678:
--
We encountered the same problem. I debugged it and found that the issue is
related to jakarta.faces.FACELETS_REFRESH_PERIOD > 0. The internal refreshing
mechanism starts reloading facelets even when they haven't changed. I noticed
the problem on pages that use facelets containing . Setting
org.apache.myfaces.CACHE_EL_EXPRESSIONS=noCache resolved the issue for us.
> Getting NPE FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)
>
>
> Key: MYFACES-4678
> URL: https://issues.apache.org/jira/browse/MYFACES-4678
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC2
> Environment: Tomcat 10.1, MyFaces 4.0.2, Weld 5.1.2, Primefaces 14.0.4
>Reporter: Robin Jansohn
>Assignee: Melloware
>Priority: Major
> Fix For: 5.0.0, 4.0.3, 4.1.0-RC3
>
> Attachments: myfaces-4678.zip, myfaces-bug.zip
>
>
> Getting a weird NPE when switching dialogs but only if I am in
> jakarta.faces.PROJECT_STAGE=Production. In Development everything works. I'll
> try to create a reproducer, for now I'll just attach the stacktrace. Maybe
> someone can already give some insights why this might be happening.
> {noformat}
> SEVERE: Cannot invoke
> "jakarta.el.ValueExpression.getValue(jakarta.el.ELContext)" because the
> return value of
> "org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)"
> is null
> java.lang.NullPointerException: Cannot invoke
> "jakarta.el.ValueExpression.getValue(jakarta.el.ELContext)" because the
> return value of
> "org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)"
> is null
> at
> org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getValue(FaceletStateValueExpression.java:114)
> at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:74)
> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:37)
> at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:170)
> at
> org.jboss.weld.module.web.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
> at
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:100)
> at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:74)
> at org.apache.el.parser.AstOr.getValue(AstOr.java:37)
> at org.apache.el.parser.AstOr.getValue(AstOr.java:37)
> at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:170)
> at
> org.jboss.weld.module.web.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
> at
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:100)
> at
> org.apache.myfaces.view.facelets.tag.TagAttributeImpl.getObject(TagAttributeImpl.java:462)
> at
> org.apache.myfaces.view.facelets.tag.TagAttributeImpl.getBoolean(TagAttributeImpl.java:138)
> at
> org.apache.myfaces.view.facelets.tag.jstl.core.IfHandler.apply(IfHandler.java:111)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.ap
[jira] [Resolved] (MYFACES-4683) Scripts executed in reverse order during ajax event
[ https://issues.apache.org/jira/browse/MYFACES-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melloware resolved MYFACES-4683. Resolution: Fixed > Scripts executed in reverse order during ajax event > --- > > Key: MYFACES-4683 > URL: https://issues.apache.org/jira/browse/MYFACES-4683 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.1.0-RC2 > Environment: Windows, Chrome >Reporter: Jamie Goodfellow >Assignee: Werner Punz >Priority: Major > Fix For: 5.0.0, 4.0.3, 4.1.0-RC3 > > > When myfaces handles an ajax request, the script tags of the rendered xhtml > fragments are executed from last to first which is the opposite of what would > happen during a regular page load. I encountered this problem because one of > my components references another component in it's constructor and the > referenced component didn't exist yet during an ajax call because of reverse > execution. I found the problem code: > .sort((node1, node2) => node1.compareDocumentPosition(node2) - 3) // > preceding 2, following == 4) > The compareDocumentPosition method compares the node2 position relative to > node1's position. If node2 is preceding node1 then the sort return value > should be 1 but in this case it will be -1 as 2 (return of > compareDocumentPosition) minus 3 is -1. The correct code should be: > .sort((node1, node2) => node2.compareDocumentPosition(node1) - 3) // > preceding 2, following == 4) > Here is a jsfiddle - [JSFiddle - Code > Playground|https://jsfiddle.net/jc03vLt5/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4683) Scripts executed in reverse order during ajax event
[ https://issues.apache.org/jira/browse/MYFACES-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885998#comment-17885998 ] Werner Punz commented on MYFACES-4683: -- The fix looks correct to me. You can merge it in, I will put this into my upstream codebase tomorrow. (I just wonder why I have the -3, I have to investigate that, there was a reason why I did it, but this needs documentation in the codebase, but thats unrelated to the fix) > Scripts executed in reverse order during ajax event > --- > > Key: MYFACES-4683 > URL: https://issues.apache.org/jira/browse/MYFACES-4683 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.1.0-RC2 > Environment: Windows, Chrome >Reporter: Jamie Goodfellow >Assignee: Werner Punz >Priority: Major > Fix For: 5.0.0, 4.0.3, 4.1.0-RC3 > > > When myfaces handles an ajax request, the script tags of the rendered xhtml > fragments are executed from last to first which is the opposite of what would > happen during a regular page load. I encountered this problem because one of > my components references another component in it's constructor and the > referenced component didn't exist yet during an ajax call because of reverse > execution. I found the problem code: > .sort((node1, node2) => node1.compareDocumentPosition(node2) - 3) // > preceding 2, following == 4) > The compareDocumentPosition method compares the node2 position relative to > node1's position. If node2 is preceding node1 then the sort return value > should be 1 but in this case it will be -1 as 2 (return of > compareDocumentPosition) minus 3 is -1. The correct code should be: > .sort((node1, node2) => node2.compareDocumentPosition(node1) - 3) // > preceding 2, following == 4) > Here is a jsfiddle - [JSFiddle - Code > Playground|https://jsfiddle.net/jc03vLt5/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4683) Scripts executed in reverse order during ajax event
[ https://issues.apache.org/jira/browse/MYFACES-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885997#comment-17885997 ] Werner Punz commented on MYFACES-4683: -- Yes must be in correct order, I absolutely agree as well! > Scripts executed in reverse order during ajax event > --- > > Key: MYFACES-4683 > URL: https://issues.apache.org/jira/browse/MYFACES-4683 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.1.0-RC2 > Environment: Windows, Chrome >Reporter: Jamie Goodfellow >Assignee: Werner Punz >Priority: Major > Fix For: 5.0.0, 4.0.3, 4.1.0-RC3 > > > When myfaces handles an ajax request, the script tags of the rendered xhtml > fragments are executed from last to first which is the opposite of what would > happen during a regular page load. I encountered this problem because one of > my components references another component in it's constructor and the > referenced component didn't exist yet during an ajax call because of reverse > execution. I found the problem code: > .sort((node1, node2) => node1.compareDocumentPosition(node2) - 3) // > preceding 2, following == 4) > The compareDocumentPosition method compares the node2 position relative to > node1's position. If node2 is preceding node1 then the sort return value > should be 1 but in this case it will be -1 as 2 (return of > compareDocumentPosition) minus 3 is -1. The correct code should be: > .sort((node1, node2) => node2.compareDocumentPosition(node1) - 3) // > preceding 2, following == 4) > Here is a jsfiddle - [JSFiddle - Code > Playground|https://jsfiddle.net/jc03vLt5/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4683) Scripts executed in reverse order during ajax event
[ https://issues.apache.org/jira/browse/MYFACES-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885994#comment-17885994 ] Melloware commented on MYFACES-4683: I submitted PR's for review > Scripts executed in reverse order during ajax event > --- > > Key: MYFACES-4683 > URL: https://issues.apache.org/jira/browse/MYFACES-4683 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.1.0-RC2 > Environment: Windows, Chrome >Reporter: Jamie Goodfellow >Assignee: Werner Punz >Priority: Major > > When myfaces handles an ajax request, the script tags of the rendered xhtml > fragments are executed from last to first which is the opposite of what would > happen during a regular page load. I encountered this problem because one of > my components references another component in it's constructor and the > referenced component didn't exist yet during an ajax call because of reverse > execution. I found the problem code: > .sort((node1, node2) => node1.compareDocumentPosition(node2) - 3) // > preceding 2, following == 4) > The compareDocumentPosition method compares the node2 position relative to > node1's position. If node2 is preceding node1 then the sort return value > should be 1 but in this case it will be -1 as 2 (return of > compareDocumentPosition) minus 3 is -1. The correct code should be: > .sort((node1, node2) => node2.compareDocumentPosition(node1) - 3) // > preceding 2, following == 4) > Here is a jsfiddle - [JSFiddle - Code > Playground|https://jsfiddle.net/jc03vLt5/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4683) Scripts executed in reverse order during ajax event
[ https://issues.apache.org/jira/browse/MYFACES-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885984#comment-17885984 ] Melloware commented on MYFACES-4683: [~werpu] i agree with the above i would expect them to be in the correct order > Scripts executed in reverse order during ajax event > --- > > Key: MYFACES-4683 > URL: https://issues.apache.org/jira/browse/MYFACES-4683 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.1.0-RC2 > Environment: Windows, Chrome >Reporter: Jamie Goodfellow >Assignee: Werner Punz >Priority: Major > > When myfaces handles an ajax request, the script tags of the rendered xhtml > fragments are executed from last to first which is the opposite of what would > happen during a regular page load. I encountered this problem because one of > my components references another component in it's constructor and the > referenced component didn't exist yet during an ajax call because of reverse > execution. I found the problem code: > .sort((node1, node2) => node1.compareDocumentPosition(node2) - 3) // > preceding 2, following == 4) > The compareDocumentPosition method compares the node2 position relative to > node1's position. If node2 is preceding node1 then the sort return value > should be 1 but in this case it will be -1 as 2 (return of > compareDocumentPosition) minus 3 is -1. The correct code should be: > .sort((node1, node2) => node2.compareDocumentPosition(node1) - 3) // > preceding 2, following == 4) > Here is a jsfiddle - [JSFiddle - Code > Playground|https://jsfiddle.net/jc03vLt5/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4683) Scripts executed in reverse order during ajax event
Jamie Goodfellow created MYFACES-4683: - Summary: Scripts executed in reverse order during ajax event Key: MYFACES-4683 URL: https://issues.apache.org/jira/browse/MYFACES-4683 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 4.1.0-RC2 Environment: Windows, Chrome Reporter: Jamie Goodfellow When myfaces handles an ajax request, the script tags of the rendered xhtml fragments are executed from last to first which is the opposite of what would happen during a regular page load. I encountered this problem because one of my components references another component in it's constructor and the referenced component didn't exist yet during an ajax call because of reverse execution. I found the problem code: .sort((node1, node2) => node1.compareDocumentPosition(node2) - 3) // preceding 2, following == 4) The compareDocumentPosition method compares the node2 position relative to node1's position. If node2 is preceding node1 then the sort return value should be 1 but in this case it will be -1 as 2 (return of compareDocumentPosition) minus 3 is -1. The correct code should be: .sort((node1, node2) => node2.compareDocumentPosition(node1) - 3) // preceding 2, following == 4) Here is a jsfiddle - [JSFiddle - Code Playground|https://jsfiddle.net/jc03vLt5/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TOBAGO-2339) Popup closes even though there are validation errors
[
https://issues.apache.org/jira/browse/TOBAGO-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884259#comment-17884259
]
Henning Nöth commented on TOBAGO-2339:
--
This is probably, because of a client side popup. Better use a popup with AJAX.
{code:xml}
Popup (AJAX)
{code}
> Popup closes even though there are validation errors
>
>
> Key: TOBAGO-2339
> URL: https://issues.apache.org/jira/browse/TOBAGO-2339
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 6.4.0
>Reporter: Carsten Dimmek
>Priority: Major
>
> Popup closes even though there are validation errors in the formular.
> In my opinion this is not correct or i expect at least an parameter to define
> the behavior
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2355) Add data attribute support to MessagesRenderer
[ https://issues.apache.org/jira/browse/TOBAGO-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2355. -- Fix Version/s: 5.13.1 6.5.1 Resolution: Fixed > Add data attribute support to MessagesRenderer > -- > > Key: TOBAGO-2355 > URL: https://issues.apache.org/jira/browse/TOBAGO-2355 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Core >Affects Versions: 5.13.0, 6.5.0 >Reporter: Carsten Dimmek >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.13.1, 6.5.1 > > > FacesMessages only support INFO, WARNING and ERROR severity levels. I need a > way to render more details to a FacesMessage so that I can specify something > similar to SUCCESS severity. The existing severity class is unfortunately not > extensible, so I would like to have data attributes on the FacesMessages to > at least be able to customize the styling of the messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2360) TypeError with columnSelector and empty sheet
[
https://issues.apache.org/jira/browse/TOBAGO-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann resolved TOBAGO-2360.
---
Fix Version/s: 5.13.1
6.5.1
Resolution: Fixed
> TypeError with columnSelector and empty sheet
> -
>
> Key: TOBAGO-2360
> URL: https://issues.apache.org/jira/browse/TOBAGO-2360
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: JavaScript
>Affects Versions: 5.13.0, 6.5.0
>Reporter: Bernd Bohmann
>Assignee: Bernd Bohmann
>Priority: Major
> Fix For: 5.13.1, 6.5.1
>
>
>
> {noformat}
> tobago-column-selector.ts:44 Uncaught TypeError: Cannot read properties of
> null (reading 'disabled')
> at get disabled (tobago-column-selector.ts:44:90)
> at ia.initSelectionListener (tobago-sheet.ts:717:52)
> at tobago-sheet.ts:208:49{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2360) TypeError with columnSelector and empty sheet
Bernd Bohmann created TOBAGO-2360:
-
Summary: TypeError with columnSelector and empty sheet
Key: TOBAGO-2360
URL: https://issues.apache.org/jira/browse/TOBAGO-2360
Project: MyFaces Tobago
Issue Type: Bug
Components: JavaScript
Affects Versions: 6.5.0, 5.13.0
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
{noformat}
Uncaught TypeError: Cannot read properties of null (reading
'disabled'){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4682) Error Message: newBodyData is undefined
Volodymyr Siedlecki created MYFACES-4682:
Summary: Error Message: newBodyData is undefined
Key: MYFACES-4682
URL: https://issues.apache.org/jira/browse/MYFACES-4682
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.3.11, 3.0.3
Reporter: Volodymyr Siedlecki
The EE8 TCK for JSF 2.3 is failing for the following tests:
com.sun.ts.tests.jsf.spec.ajax.keyword.URLClient
- ajaxAllKeywordTest
- ajaxFormKeywordTest
- ajaxNoneKeywordTest
- ajaxThisKeywordTest
They all seem to report the same exception in the JavaScript code:
{code:java}
Error Message: newBodyData is undefined
Error Name:
clientError Server error name: TypeError
Note, this message is
only sent, because project stage is development and no other error listeners
are registered.{code}
{code:java}
TypeError: newBodyData is undefined_replaceBody
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8799
processUpdate
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8269
processChanges
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8211
processResponse
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7901
response
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10039
response
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10519
onsuccess
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7443
hitch
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2408
mixMaps
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2439
send
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7345
enqueue
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:6148
xhrQueuedPost
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8897
request
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:9688
request
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10476
anonymous
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development
line 10178 > Function:3chain
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10178
chain
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10542
onclick
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/ajaxAllKeyword1.xhtml:1 {code}
I haven't tested 3.0.3, but I except the same issue. I will follow up to verify.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2359) Aria-label on column selector in sheet
Bernd Bohmann created TOBAGO-2359: - Summary: Aria-label on column selector in sheet Key: TOBAGO-2359 URL: https://issues.apache.org/jira/browse/TOBAGO-2359 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 6.5.0, 5.13.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2351) tabChange javascript event for TabGroup (reloadTab|reloadPage) switchType
[ https://issues.apache.org/jira/browse/TOBAGO-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2351. --- Resolution: Fixed > tabChange javascript event for TabGroup (reloadTab|reloadPage) switchType > - > > Key: TOBAGO-2351 > URL: https://issues.apache.org/jira/browse/TOBAGO-2351 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core, JavaScript >Affects Versions: 5.13.0, 6.5.0 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 5.13.1, 6.5.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2358) Updating JDK for runtime and build time
Udo Schnurpfeil created TOBAGO-2358: --- Summary: Updating JDK for runtime and build time Key: TOBAGO-2358 URL: https://issues.apache.org/jira/browse/TOBAGO-2358 Project: MyFaces Tobago Issue Type: Task Components: Build Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil The minimum JDK requirements in the active branches are outdated and need to be updated ||Branch||Runtime JDK old||Runtime JDK new||Build Time JDK old||Build Time JDK new|| |Tobago 6|8|11 or 17 (?)| | | |Tobago 5|8|11 or 17 (?)| | | |Tobago 4|8|8| | | |Tobago 2|7|8| | | -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2357) Enhance code quality with Maven plugin: forbiddenapis
Udo Schnurpfeil created TOBAGO-2357: --- Summary: Enhance code quality with Maven plugin: forbiddenapis Key: TOBAGO-2357 URL: https://issues.apache.org/jira/browse/TOBAGO-2357 Project: MyFaces Tobago Issue Type: Task Components: Build Reporter: Udo Schnurpfeil Checking: * Avoid using default locale * ... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2356) Replace animal-sniffer-plugin with Java compiler option "-release"
Udo Schnurpfeil created TOBAGO-2356: --- Summary: Replace animal-sniffer-plugin with Java compiler option "-release" Key: TOBAGO-2356 URL: https://issues.apache.org/jira/browse/TOBAGO-2356 Project: MyFaces Tobago Issue Type: Task Components: Build Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil The animal-sniffer-plugin has only support until JDK 8. With Java 9 comes a new compiler option -release (also replacing -source and -target) to check also the JDK dependencies of the code, to avoid using future features of the JDK when using a newer compiler. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TOBAGO-2252) Add lazy loading support to selectOneList/selectManyList
[
https://issues.apache.org/jira/browse/TOBAGO-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882075#comment-17882075
]
Henning Nöth commented on TOBAGO-2252:
--
Suggestion:
Implement a tc:filter component which is similar to tc:suggest. The "filter"
attribute should have the value "server".
{code:xml}
{code}
> Add lazy loading support to selectOneList/selectManyList
>
>
> Key: TOBAGO-2252
> URL: https://issues.apache.org/jira/browse/TOBAGO-2252
> Project: MyFaces Tobago
> Issue Type: New Feature
> Components: Core
>Reporter: Carsten Dimmek
>Assignee: Henning Nöth
>Priority: Minor
>
> Add support for lazy loading the list after entering a defined number of
> characters, similar to the suggest component
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2355) Add data attribute support to MessagesRenderer
Carsten Dimmek created TOBAGO-2355: -- Summary: Add data attribute support to MessagesRenderer Key: TOBAGO-2355 URL: https://issues.apache.org/jira/browse/TOBAGO-2355 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 6.5.0 Reporter: Carsten Dimmek FacesMessages only support INFO, WARNING and ERROR severity levels. I need a way to render more details to a FacesMessage so that I can specify something similar to SUCCESS severity. The existing severity class is unfortunately not extensible, so I would like to have data attributes on the FacesMessages to at least be able to customize the styling of the messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881418#comment-17881418 ] Werner Punz commented on MYFACES-4679: -- Just did all the merges! all from all 2.x versions onwards, every version should have the fixes in now for appendIssuingItem! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Fix For: 2.0.25, 2.1.19, 2.3.11, 3.0.3, 2.2.16, 2.3-next-M9, > 5.0.0, 4.0.3, 4.1.0-RC3 > > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4679. -- Resolution: Fixed > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Fix For: 2.0.25, 2.1.19, 2.3.11, 3.0.3, 2.2.16, 2.3-next-M9, > 5.0.0, 4.0.3, 4.1.0-RC3 > > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881112#comment-17881112 ] Volodymyr Siedlecki commented on MYFACES-4679: -- Thank you! Looking forward to the PRs :) > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2354) Render popup inside button/link
Henning Nöth created TOBAGO-2354:
Summary: Render popup inside button/link
Key: TOBAGO-2354
URL: https://issues.apache.org/jira/browse/TOBAGO-2354
Project: MyFaces Tobago
Issue Type: Bug
Components: Core, JavaScript
Affects Versions: 6.5.0, 5.13.0
Reporter: Henning Nöth
Currently a tc:popup must be rendered on the site. You have to write:
{code:xml}
...
{code}
It should be possible to write:
{code:xml}
...
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (TOBAGO-2331) Lazy sheet: Ajax request contains too many keys
[ https://issues.apache.org/jira/browse/TOBAGO-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth reopened TOBAGO-2331: -- > Lazy sheet: Ajax request contains too many keys > --- > > Key: TOBAGO-2331 > URL: https://issues.apache.org/jira/browse/TOBAGO-2331 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core, JavaScript >Affects Versions: 5.12.0, 6.4.0 >Reporter: Henning Nöth >Priority: Critical > Fix For: 5.13.0, 6.5.0 > > > If a lazy sheet contains form elements (e.g. a tc:in or a tc:button), those > IDs/keys are put into the Ajax request to load the next batch of a lazy sheet. > There is a maximum number of keys in a request, so an error will occur if the > user scrolls long enough. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880786#comment-17880786 ] Werner Punz commented on MYFACES-4679: -- Ok the backported code works on 2.3, my integration tests also pass on the code. I will also backport it to the other 2.x branches given that the behaviorEvent system spans the entire 2.x line of code, and then issue merge requests for good, should be done hopefully tomorrow then to get this issue to a closure! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4681) Faces 4.1 TCK Failure: headRenderPassthroughTest - Head ID Not Rendered
Volodymyr Siedlecki created MYFACES-4681:
Summary: Faces 4.1 TCK Failure: headRenderPassthroughTest - Head
ID Not Rendered
Key: MYFACES-4681
URL: https://issues.apache.org/jira/browse/MYFACES-4681
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.1.0-RC2
Reporter: Volodymyr Siedlecki
Test:
[https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/old-tck/source/src/com/sun/ts/tests/jsf/spec/render/head/URLClient.java#L85]
We fail to render the head id for this test even though it's specified in the
facelet.
App:
[https://github.com/jakartaee/faces/tree/fbaccab3da18ee26d40cd6f77d91de79ef1c7b15/tck/old-tck/source/src/web/jsf/spec/render/head|https://github.com/jakartaee/faces/blob/fbaccab3da18ee26d40cd6f77d91de79ef1c7b15/tck/old-tck/source/src/web/jsf/spec/render/head/passthroughtest_facelet.xhtml#L29]
Related Spec Issue: [https://github.com/jakartaee/faces/issues/1760]
As noted by BalcusC's comment, the output mode is controllable, not by the
doctype, but by the {{}} in {{faces-config.xml.}}
{{By default, the facelet processing is the HTML5 output. This means the
publicId and systemId should be null as there is no DTD. This is not the case
in our code, as we create with doctype using the declaration from the xhtml
page. }}
{{Doctype initialization: }}
{{[https://github.com/apache/myfaces/blob/4.1.x/impl/src/main/java/org/apache/myfaces/view/facelets/compiler/CompilationManager.java#L148]}}
{{This leads to the HTML5 check to fail when attempting to render the IDs in
the head and body elements.}}
{{[https://github.com/apache/myfaces/blob/4.1.x/impl/src/main/java/org/apache/myfaces/renderkit/html/HtmlHeadRenderer.java#L64-L67]}}
{{[https://github.com/apache/myfaces/blob/4.1.x/impl/src/main/java/org/apache/myfaces/renderkit/html/util/HtmlRendererUtils.java#L1785-L1787]
}}
{{Please review in case anything looks incorrect. }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2331) Lazy sheet: Ajax request contains too many keys
[ https://issues.apache.org/jira/browse/TOBAGO-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2331. --- Resolution: Fixed > Lazy sheet: Ajax request contains too many keys > --- > > Key: TOBAGO-2331 > URL: https://issues.apache.org/jira/browse/TOBAGO-2331 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core, JavaScript >Affects Versions: 5.12.0, 6.4.0 >Reporter: Henning Nöth >Priority: Critical > Fix For: 6.5.0, 5.13.0 > > > If a lazy sheet contains form elements (e.g. a tc:in or a tc:button), those > IDs/keys are put into the Ajax request to load the next batch of a lazy sheet. > There is a maximum number of keys in a request, so an error will occur if the > user scrolls long enough. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2353) File upload client validation
Udo Schnurpfeil created TOBAGO-2353: --- Summary: File upload client validation Key: TOBAGO-2353 URL: https://issues.apache.org/jira/browse/TOBAGO-2353 Project: MyFaces Tobago Issue Type: Improvement Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4680) 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
[
https://issues.apache.org/jira/browse/MYFACES-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880376#comment-17880376
]
Volodymyr Siedlecki commented on MYFACES-4680:
--
Never mind – that was some other issue.
This PR gets us half way to fixing this TCK failure:
[https://github.com/apache/myfaces/pull/748] (it sends the websocket message,
and thus invokes the behavior function)
However, I get an JS exception stating that a form must exist.
> 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
> ---
>
> Key: MYFACES-4680
> URL: https://issues.apache.org/jira/browse/MYFACES-4680
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.15, 2.3.10, 2.3-next-M8, 4.0.0, 4.1.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces23-websocket.war
>
>
> The app expects "pushed!" to display when the "push" button is pressed. It
> is not, and the test fails.
> Ajax requests do not occur when they are registered a websocket tag, from
> what I could gather. It seems like the renderAjaxOutput behavior isn't
> registered / called with the faces.push.init script.
> MyFaces generated code (see behavior param (1) – second to last):
> {code:java}
> faces.push.init('j_id_c','/test-faces23-websocket/jakarta.faces.push/view?76379b861759b95fa70c118d2e05d29f','view',function(){document.getElementById('opened').innerHTML='yes';},null,null,null,{renderAjaxOutput:[function(event){myfaces.ab('j_id_c',event,'renderAjaxOutput','','ajaxOutput')}]},true);{code}
> Facelet:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> {code:java}
> onopen="function(){document.getElementById('opened').innerHTML='yes';}">
>
> {code}
> Link to Test:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/test/java/ee/jakarta/tck/faces/test/javaee8/websocket/Spec1396IT.java#L94]
> I test the same TCK app on Mojarra, and it sends out two XHR requests when
> the button is clicked. One for the button click and another for the
> renderAjaxOutput event.
> MyFaces only handles the one XHR for the button click. Neither do I see the
> onMessage invoked, which per the javadoc should trigger the behavior (
> "behavior param: Client behavior functions to be invoked when specific
> message is received.")?
> Docs:
> [1)
> https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push|https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4680) 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
[
https://issues.apache.org/jira/browse/MYFACES-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880351#comment-17880351
]
Volodymyr Siedlecki commented on MYFACES-4680:
--
I'm missing something here – the {{behaviors}} callback should be for the web
socket, not the XHR request.
Let me do some more investigation into this.
> 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
> ---
>
> Key: MYFACES-4680
> URL: https://issues.apache.org/jira/browse/MYFACES-4680
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.15, 2.3.10, 2.3-next-M8, 4.0.0, 4.1.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces23-websocket.war
>
>
> The app expects "pushed!" to display when the "push" button is pressed. It
> is not, and the test fails.
> Ajax requests do not occur when they are registered a websocket tag, from
> what I could gather. It seems like the renderAjaxOutput behavior isn't
> registered / called with the faces.push.init script.
> MyFaces generated code (see behavior param (1) – second to last):
> {code:java}
> faces.push.init('j_id_c','/test-faces23-websocket/jakarta.faces.push/view?76379b861759b95fa70c118d2e05d29f','view',function(){document.getElementById('opened').innerHTML='yes';},null,null,null,{renderAjaxOutput:[function(event){myfaces.ab('j_id_c',event,'renderAjaxOutput','','ajaxOutput')}]},true);{code}
> Facelet:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> {code:java}
> onopen="function(){document.getElementById('opened').innerHTML='yes';}">
>
> {code}
> Link to Test:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/test/java/ee/jakarta/tck/faces/test/javaee8/websocket/Spec1396IT.java#L94]
> I test the same TCK app on Mojarra, and it sends out two XHR requests when
> the button is clicked. One for the button click and another for the
> renderAjaxOutput event.
> MyFaces only handles the one XHR for the button click. Neither do I see the
> onMessage invoked, which per the javadoc should trigger the behavior (
> "behavior param: Client behavior functions to be invoked when specific
> message is received.")?
> Docs:
> [1)
> https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push|https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2352) Fire client-side CustomEvent for tc:operation
[ https://issues.apache.org/jira/browse/TOBAGO-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2352. -- Fix Version/s: 5.13.1 6.5.1 Resolution: Fixed > Fire client-side CustomEvent for tc:operation > - > > Key: TOBAGO-2352 > URL: https://issues.apache.org/jira/browse/TOBAGO-2352 > Project: MyFaces Tobago > Issue Type: New Feature > Components: JavaScript >Affects Versions: 5.13.0, 6.5.0 >Reporter: Henning Nöth >Assignee: Henning Nöth >Priority: Major > Fix For: 5.13.1, 6.5.1 > > > Fire a JavaScript custom event (show/shown/hide/hidden) for tc:operation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2352) Fire client-side CustomEvent for tobago-behavior
Henning Nöth created TOBAGO-2352: Summary: Fire client-side CustomEvent for tobago-behavior Key: TOBAGO-2352 URL: https://issues.apache.org/jira/browse/TOBAGO-2352 Project: MyFaces Tobago Issue Type: New Feature Components: JavaScript Affects Versions: 6.5.0, 5.13.0 Reporter: Henning Nöth Assignee: Henning Nöth Fire a JavaScript custom event (show/shown/hide/hidden) for tc:operation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4680) 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
[
https://issues.apache.org/jira/browse/MYFACES-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879991#comment-17879991
]
Volodymyr Siedlecki edited comment on MYFACES-4680 at 9/7/24 1:46 AM:
--
This looks like a server side script generation issue – I will look into it see
what kind of fix I can provide.
https://github.com/apache/myfaces/blob/4.1.x/impl/src/main/java/org/apache/myfaces/push/WebsocketComponentRenderer.java#L237
was (Author: volosied):
This looks like a server side script generation issue – I will look into it see
what kind of fix I can provide.
> 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
> ---
>
> Key: MYFACES-4680
> URL: https://issues.apache.org/jira/browse/MYFACES-4680
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.15, 2.3.10, 2.3-next-M8, 4.0.0, 4.1.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces23-websocket.war
>
>
> Ajax requests do not occur when they are registered a websocket tag, from
> what I could gather. It seems like the renderAjaxOutput behavior isn't
> registered with the faces.push.init script.
> MyFaces generated code (see behavior param (1) – second to last):
> <!--
> faces.push.init('j_id_a','/test-faces23-websocket/jakarta.faces.push/user?7d67dec51e155ff40267fab691468b7b','user',function()\{document.getElementById('opened').innerHTML='yes';},function(message)\{document.getElementById('message').innerHTML=message;},null,null,{*}{}{*},true);
> //-->
> Facelet:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> {code:java}
> onopen="function(){document.getElementById('opened').innerHTML='yes';}">
>
> {code}
> Link to Test:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/test/java/ee/jakarta/tck/faces/test/javaee8/websocket/Spec1396IT.java#L94]
> I test the same TCK app on Mojarra, and it sends out two XHR requests when
> the button is clicked. One for the button click and another for the
> renderAjaxOutput event.
> MyFaces only handle the XHR for the button click.
> Docs:
> [1)
> https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push|https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879880#comment-17879880 ] Werner Punz commented on MYFACES-4679: -- ok thanks, I guess I will have to revisit the error handling changes again! I will merge later tonight with the fixes for appendIssuingItem and will start on a backport to 2.3 > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879878#comment-17879878 ] Volodymyr Siedlecki commented on MYFACES-4679: -- Failures look to be caused but the new error handling changes. But this change is good to merge. Can you also create a PR for 2.2 / 2.3 (I would like a user of ours to test it out, too). Thank you > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4676) Error Data Paylod Not Following Spec in Faces 4.0
[
https://issues.apache.org/jira/browse/MYFACES-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879876#comment-17879876
]
Volodymyr Siedlecki commented on MYFACES-4676:
--
I think this is causing 3 new errors in the TCK: (linked the 4.1.0 TCK but I
tested 4.0 code)
{code:java}
Name: undefined Error: decode: A RuntimeException Has Occurred!{code}
http://localhost:9080/test-faces22-ajax/issue2179-page2.xhtml
https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax_selenium/Issue2179IT.java#L49
{code:java}
Error from undefined {code}
http://localhost:9080/test-faces22-ajax/ajaxScriptError.xhtml
https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax_selenium/Issue3473IT.java#L35
{code:java}
Error from undefined {code}
http://localhost:9080/test-faces22-ajax/exceptionDuringRender.xhtml
https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax_selenium/Issue3171IT.java#L35
> Error Data Paylod Not Following Spec in Faces 4.0
> -
>
> Key: MYFACES-4676
> URL: https://issues.apache.org/jira/browse/MYFACES-4676
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 4.0.0, 4.1.0-RC2
>Reporter: Thomas Smith
>Assignee: Werner Punz
>Priority: Trivial
> Fix For: 5.0.0, 4.0.3, 4.1.0-RC3
>
> Attachments: Screenshot 2024-07-22 153633.png, test-faces22-ajax.war
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The [Error Data Payload (Table 16)|#a6973]] outlined in the spec isn't
> followed. As seen in the screenshot below something seems to be going wrong
> for responseText, responseCode, and status. Additionally, description and
> responseXML aren't included in the payload.
> !Screenshot 2024-07-22 153633.png|width=541,height=408!
> The response from the server still seems to be accurate:
> {code:java}
> encoding="UTF-8"?>org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException{code}
> The information seems to be lost somewhere in between the server response and
> error payload generation.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879757#comment-17879757 ] Werner Punz commented on MYFACES-4679: -- This looks like an issue related to other changes not my fix on the js files. Given the second test passes! I just updated the JS files on my side nothing else (aka appendIssuingItem) Question is can we go ahead with my fix or do you wont to look deeper into the issue first why it fails? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2351) tabChange javascript event for TabGroup (reloadTab|reloadPage) switchType
Bernd Bohmann created TOBAGO-2351: - Summary: tabChange javascript event for TabGroup (reloadTab|reloadPage) switchType Key: TOBAGO-2351 URL: https://issues.apache.org/jira/browse/TOBAGO-2351 Project: MyFaces Tobago Issue Type: Improvement Components: Core, JavaScript Affects Versions: 6.5.0, 5.13.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2350) Remove placeholder for file upload
Henning Nöth created TOBAGO-2350: Summary: Remove placeholder for file upload Key: TOBAGO-2350 URL: https://issues.apache.org/jira/browse/TOBAGO-2350 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 6.5.0, 5.13.0 Reporter: Henning Nöth Remove the placeholder attribute, because it has no effect for -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879362#comment-17879362
]
Volodymyr Siedlecki commented on MYFACES-4666:
--
I added a draft PR here: [https://github.com/apache/myfaces/pull/747]
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Trivial
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2347) tc:selectOneChoice validates when disabled
[ https://issues.apache.org/jira/browse/TOBAGO-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2347. -- Fix Version/s: 5.13.1 6.5.1 Resolution: Fixed > tc:selectOneChoice validates when disabled > -- > > Key: TOBAGO-2347 > URL: https://issues.apache.org/jira/browse/TOBAGO-2347 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 6.5.0 >Reporter: Carsten Dimmek >Assignee: Henning Nöth >Priority: Major > Fix For: 5.13.1, 6.5.1 > > > A disabled selectOneChoice gets validated -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878948#comment-17878948 ] Werner Punz edited comment on MYFACES-4679 at 9/3/24 8:30 PM: -- 4606 is messy and is overcomplicating things for little gain. But lets see whether we can fix this on the client side! was (Author: werpu): I will have a look at it tonight! The append issuing item is only working on checkboxes if the checkbox itself issues the request and there the same rule applies if it issues the request and it is sending a behavior event then it is not appended, and that might be the culprit here because it is a "natural value holder" unlike a button! But even then the question is do we want the key value pair appended for behavior events, if we add the checkbox to the execution list or make an execute form then it is appended anyway! The append issuing item is just functionality on top for debugging purposes. 4606 is messy and is overomplicating things for little gain. But lets see whether we can fix this on the client side! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879007#comment-17879007
]
Werner Punz edited comment on MYFACES-4679 at 9/3/24 8:29 PM:
--
Ok I now have had a look at it. The only event atm which can trigger an action
automatically is click! I tried it and it seems there is no other event which
automatically can issue a submit (unless I have missed something)!
(manual hooks providing jsf.ajax.requests are a different thing)
so the solution to this second issue simply would be to whitelist click as only
behavioral pattern which is allowed to append the issuing item!
This should work
a) No action is set then nothing is executed
b) Exceute @none despite action being set, the same (tried it the action does
not get called in this case)
c) Listener present the listener is called and then the action
What do you guys think?
I played this scenario through with a slightly changed codebase and it seems to
work out!
Here is my playthrough secnario:
{code:xml}
{code}
This implicitly also covers the case failing before!
was (Author: werpu):
Ok I now have had a look at it. The only event atm which can trigger an action
automatically is click! I tried it and it seems there is no other event which
automatically can issue a submit (unless I have missed something)!
(manual hooks providing jsf.ajax.requests are a different thing)
so the solution to this second issue simply would be to whitelist click as only
behavioral pattern which is allowed to append the issuing item!
This should work
a) No action is set then nothing is executed
b) Exceute @none despite action being set, the same (tried it the action does
not get called in this case)
c) Listener present the listener is called and then the action
What do you guys think?
I played this scenario through with a slightly changed codebase and it seems to
work out!
Here is my playthrough secnario:
{code:xml}
{code}
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879014#comment-17879014 ] Werner Punz edited comment on MYFACES-4679 at 9/3/24 8:28 PM: -- the three merge requests now have the click fix in, please give them a shot! PS: We should find a cleaner way to handle the submits/actions on the server side! The code there definitely needs an overhaul. I personally would prefer one single universal action execution marker, if possible instead of detecting a key value pair and other patterns! was (Author: werpu): the three merge requests now have the click fix in, please give them a shot! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879014#comment-17879014 ] Werner Punz edited comment on MYFACES-4679 at 9/3/24 8:27 PM: -- the three merge requests now have the click fix in, please give them a shot! was (Author: werpu): https://github.com/apache/myfaces/pull/744 now has the changes in, please give it a shot! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879014#comment-17879014 ] Werner Punz commented on MYFACES-4679: -- https://github.com/apache/myfaces/pull/744 now has the changes in, please give it a shot! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879007#comment-17879007
]
Werner Punz edited comment on MYFACES-4679 at 9/3/24 8:21 PM:
--
Ok I now have had a look at it. The only event atm which can trigger an action
automatically is click! I tried it and it seems there is no other event which
automatically can issue a submit (unless I have missed something)!
(manual hooks providing jsf.ajax.requests are a different thing)
so the solution to this second issue simply would be to whitelist click as only
behavioral pattern which is allowed to append the issuing item!
This should work
a) No action is set then nothing is executed
b) Exceute @none despite action being set, the same (tried it the action does
not get called in this case)
c) Listener present the listener is called and then the action
What do you guys think?
I played this scenario through with a slightly changed codebase and it seems to
work out!
Here is my playthrough secnario:
{code:xml}
{code}
was (Author: werpu):
Ok I now have had a look at it. The only event atm which can trigger an action
automatically is click! I tried it and it seems there is no other event which
automatically can issue a submit (unless I have missed something)!
(manual hooks providing jsf.ajax.requests are a different thing)
so the solution to this second issue simply would be to whitelist click as only
behavioral pattern which is allowed to append the issuing item!
This should work
a) No action is set then nothing is executed
b) Exceute @none despite action being set, the same (tried it the action does
not get called in this case)
c) Listener present the listener is called and then the action
What do you guys think?
I played this scenario through with a slightly changed codebase and it seems to
work out!
Here is my playthrough secnario:
{code:xhtml}
{code}
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879007#comment-17879007
]
Werner Punz edited comment on MYFACES-4679 at 9/3/24 8:21 PM:
--
Ok I now have had a look at it. The only event atm which can trigger an action
automatically is click! I tried it and it seems there is no other event which
automatically can issue a submit (unless I have missed something)!
(manual hooks providing jsf.ajax.requests are a different thing)
so the solution to this second issue simply would be to whitelist click as only
behavioral pattern which is allowed to append the issuing item!
This should work
a) No action is set then nothing is executed
b) Exceute @none despite action being set, the same (tried it the action does
not get called in this case)
c) Listener present the listener is called and then the action
What do you guys think?
I played this scenario through with a slightly changed codebase and it seems to
work out!
Here is my playthrough secnario:
{code:xhtml}
{code}
was (Author: werpu):
Ok I now have had a look at it. The only event atm which can trigger an action
automatically is click! I tried it and it seems there is no other event which
automatically can issue a submit (unless I have missed something)!
(manual hooks providing jsf.ajax.requests are a different thing)
so the solution to this second issue simply would be to whitelist click as only
behavioral pattern which is allowed to append the issuing item!
This should work
a) No action is set then nothing is executed
b) Exceute @none despite action being set, the same (tried it the action does
not get called in this case)
c) Listener present the listener is called and then the action
What do you guys think?
I played this scenario through with a slightly changed codebase and it seems to
work out!
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879007#comment-17879007
]
Werner Punz edited comment on MYFACES-4679 at 9/3/24 8:21 PM:
--
Ok I now have had a look at it. The only event atm which can trigger an action
automatically is click! I tried it and it seems there is no other event which
automatically can issue a submit (unless I have missed something)!
(manual hooks providing jsf.ajax.requests are a different thing)
so the solution to this second issue simply would be to whitelist click as only
behavioral pattern which is allowed to append the issuing item!
This should work
a) No action is set then nothing is executed
b) Exceute @none despite action being set, the same (tried it the action does
not get called in this case)
c) Listener present the listener is called and then the action
What do you guys think?
I played this scenario through with a slightly changed codebase and it seems to
work out!
Here is my playthrough secnario:
{code:xml}
{code}
was (Author: werpu):
Ok I now have had a look at it. The only event atm which can trigger an action
automatically is click! I tried it and it seems there is no other event which
automatically can issue a submit (unless I have missed something)!
(manual hooks providing jsf.ajax.requests are a different thing)
so the solution to this second issue simply would be to whitelist click as only
behavioral pattern which is allowed to append the issuing item!
This should work
a) No action is set then nothing is executed
b) Exceute @none despite action being set, the same (tried it the action does
not get called in this case)
c) Listener present the listener is called and then the action
What do you guys think?
I played this scenario through with a slightly changed codebase and it seems to
work out!
Here is my playthrough secnario:
{code:xml}
{code}
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879007#comment-17879007 ] Werner Punz edited comment on MYFACES-4679 at 9/3/24 8:18 PM: -- Ok I now have had a look at it. The only event atm which can trigger an action automatically is click! I tried it and it seems there is no other event which automatically can issue a submit (unless I have missed something)! (manual hooks providing jsf.ajax.requests are a different thing) so the solution to this second issue simply would be to whitelist click as only behavioral pattern which is allowed to append the issuing item! This should work a) No action is set then nothing is executed b) Exceute @none despite action being set, the same (tried it the action does not get called in this case) c) Listener present the listener is called and then the action What do you guys think? I played this scenario through with a slightly changed codebase and it seems to work out! was (Author: werpu): Ok I now have had a look at it. The only event atm which can trigger an action automatically is click! I tried it and it seems there is no other event which automatically can issue a submit (unless I have missed something)! (manual hooks providing jsf.ajax.requests are a different thing) so the solution to this second issue simply would be to whitelist click as only behavioral pattern which is allowed to append the issuing item! This should work a) No action is set then nothing is executed b) Exceute @none despite action being set, the same (tried it the action does not get called in this case) c) Listener present the listener is called and then the action What do you guys think? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879007#comment-17879007 ] Werner Punz commented on MYFACES-4679: -- Ok I now have had a look at it. The only event atm which can trigger an action automatically is click! I tried it and it seems there is no other event which automatically can issue a submit (unless I have missed something)! (manual hooks providing jsf.ajax.requests are a different thing) so the solution to this second issue simply would be to whitelist click as only behavioral pattern which is allowed to append the issuing item! This should work a) No action is set then nothing is executed b) Exceute @none despite action being set, the same (tried it the action does not get called in this case) c) Listener present the listener is called and then the action What do you guys think? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878948#comment-17878948 ] Werner Punz edited comment on MYFACES-4679 at 9/3/24 4:58 PM: -- I will have a look at it tonight! The append issuing item is only working on checkboxes if the checkbox itself issues the request and there the same rule applies if it issues the request and it is sending a behavior event then it is not appended, and that might be the culprit here because it is a "natural value holder" unlike a button! But even then the question is do we want the key value pair appended for behavior events, if we add the checkbox to the execution list or make an execute form then it is appended anyway! The append issuing item is just functionality on top for debugging purposes. was (Author: werpu): I will have a look at it tonight! The append issuing item is only working on checkboxes if the checkbox itself issues the request and there the same rule applies if it issues the request and it is sending a behavior event then it is not appended, and that might be the culprit here because it is a "natural value holder" unlike a button! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878948#comment-17878948 ] Werner Punz edited comment on MYFACES-4679 at 9/3/24 4:59 PM: -- I will have a look at it tonight! The append issuing item is only working on checkboxes if the checkbox itself issues the request and there the same rule applies if it issues the request and it is sending a behavior event then it is not appended, and that might be the culprit here because it is a "natural value holder" unlike a button! But even then the question is do we want the key value pair appended for behavior events, if we add the checkbox to the execution list or make an execute form then it is appended anyway! The append issuing item is just functionality on top for debugging purposes. 4606 is messy and is overomplicating things for little gain. But lets see whether we can fix this on the client side! was (Author: werpu): I will have a look at it tonight! The append issuing item is only working on checkboxes if the checkbox itself issues the request and there the same rule applies if it issues the request and it is sending a behavior event then it is not appended, and that might be the culprit here because it is a "natural value holder" unlike a button! But even then the question is do we want the key value pair appended for behavior events, if we add the checkbox to the execution list or make an execute form then it is appended anyway! The append issuing item is just functionality on top for debugging purposes. > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878950#comment-17878950 ] Volodymyr Siedlecki commented on MYFACES-4679: -- I agree – 4606 is a bit messy and is over complicating things... :( > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878948#comment-17878948 ] Werner Punz edited comment on MYFACES-4679 at 9/3/24 4:57 PM: -- I will have a look at it tonight! The append issuing item is only working on checkboxes if the checkbox itself issues the request and there the same rule applies if it issues the request and it is sending a behavior event then it is not appended, and that might be the culprit here because it is a "natural value holder" unlike a button! Either way 4606 in my opinion is a mess for little gain! was (Author: werpu): I will have a look at it tonight! The append issuing item is only working on checkboxes if the checkbox itself issues the request and there the same rule applies if it issues the request and it is sending a behavior event then it is not appended, and that might be the culprit here because it is a "natural value holder" unlike a button! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878948#comment-17878948 ] Werner Punz edited comment on MYFACES-4679 at 9/3/24 4:57 PM: -- I will have a look at it tonight! The append issuing item is only working on checkboxes if the checkbox itself issues the request and there the same rule applies if it issues the request and it is sending a behavior event then it is not appended, and that might be the culprit here because it is a "natural value holder" unlike a button! was (Author: werpu): I will have a look at it tonight! The append issuing item is only working on checkboxes if the checkbox itself issues the request and there the same rule applies if it issues the request and it is sending a behavior event then it is not appended, and that might be the culprit here because it is a "natural value holder" unlike a button! Either way 4606 in my opinion is a mess for little gain! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878948#comment-17878948 ] Werner Punz commented on MYFACES-4679: -- I will have a look at it tonight! The append issuing item is only working on checkboxes if the checkbox itself issues the request and there the same rule applies if it issues the request and it is sending a behavior event then it is not appended, and that might be the culprit here because it is a "natural value holder" unlike a button! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878944#comment-17878944 ] Volodymyr Siedlecki commented on MYFACES-4679: -- To add some clarification for the example above since it uses checkboxes – I believe the previous checkbox regression with 4606 only applied if the checkbox was ajax-enabled – not the submit button in the form. >From what I remember, the name/value pair shouldn't be sent when the checkbox >is unchecked. However, the 745 proposed fix doesn't reach the checkbox / radio >handling within the appendIssuingItem method because the behavior event >attribute is found. > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2348) Lazy sheet: scrollposition under herder so it's not visible
Henning Nöth created TOBAGO-2348: Summary: Lazy sheet: scrollposition under herder so it's not visible Key: TOBAGO-2348 URL: https://issues.apache.org/jira/browse/TOBAGO-2348 Project: MyFaces Tobago Issue Type: Bug Components: Core, JavaScript Affects Versions: 6.5.0, 5.13.0 Reporter: Henning Nöth If using a lazy sheet without the column attribute, the scroll position is not "0". The scroll position is set to show the first row, so the header is scrolled up and is not visible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TOBAGO-2347) tc:selectOneChoice validates when disabled
[ https://issues.apache.org/jira/browse/TOBAGO-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878793#comment-17878793 ] Carsten Dimmek commented on TOBAGO-2347: https://github.com/apache/myfaces-tobago/pull/5411 > tc:selectOneChoice validates when disabled > -- > > Key: TOBAGO-2347 > URL: https://issues.apache.org/jira/browse/TOBAGO-2347 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 6.5.0 >Reporter: Carsten Dimmek >Priority: Major > > A disabled selectOneChoice gets validated -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2347) tc:selectOne
Carsten Dimmek created TOBAGO-2347: -- Summary: tc:selectOne Key: TOBAGO-2347 URL: https://issues.apache.org/jira/browse/TOBAGO-2347 Project: MyFaces Tobago Issue Type: Bug Components: Core Reporter: Carsten Dimmek -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878624#comment-17878624 ] Werner Punz edited comment on MYFACES-4679 at 9/2/24 4:24 PM: -- [~volosied]I will check the case you have reported on what is passed into the ajax cycle there! A select many check box as issuer was not covered yet, that is independent of the 4606! was (Author: werpu): [~volosied]I will check the case you have reported on what is passed into the ajax cycle there! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878624#comment-17878624 ] Werner Punz edited comment on MYFACES-4679 at 9/2/24 4:24 PM: -- [~volosied]I will check the case you have reported on what is passed into the ajax cycle there! was (Author: werpu): [~volosied]I will check the case you have reported on what is passed into the ajax cycle there! A select many check box as issuer was not covered yet, that is independent of the 4606! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878624#comment-17878624 ] Werner Punz commented on MYFACES-4679: -- [~volosied]I will check the case you have reported on what is passed into the ajax cycle there! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2346) File upload: There are warning logs when there is a non required empty tag
Udo Schnurpfeil created TOBAGO-2346: --- Summary: File upload: There are warning logs when there is a non required empty tag Key: TOBAGO-2346 URL: https://issues.apache.org/jira/browse/TOBAGO-2346 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 6.5.0, 5.13.0 Reporter: Udo Schnurpfeil If the filename is blank, there is a warning. Should not be logged, when there is no content. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878589#comment-17878589
]
Volodymyr Siedlecki commented on MYFACES-4679:
--
BalusC responded: [https://www.eclipse.org/lists/faces-dev/msg00416.html]
{code:java}
The action event should only be queued when the action event is fired (which is
"click" in case of commandButton+ajax).{code}
He also created a issue in Mojarra here:
[https://github.com/eclipse-ee4j/mojarra/issues/5488]
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878588#comment-17878588
]
Volodymyr Siedlecki commented on MYFACES-4679:
--
I tested 4606 against your 745 (4.0) PR, but it doesn't send the client id as
part of the ajax request.
{code:java}
{code}
{code:java}
{code}
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878448#comment-17878448 ] Werner Punz edited comment on MYFACES-4679 at 9/2/24 11:43 AM: --- Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases. I have the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! PS: We will have to fix this for 2.3 as well, I will add the fix later this week! [~volosied] please review it and if it solves your problem, so that we can merge! FYI, the final fix is as I have proposed that we do not append the issuing item for certain cases, the behavior events are such a case (and the only one were we have to add such an exclusion, for now) was (Author: werpu): Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases. I have the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem, so that we can merge! FYI, the final fix is as I have proposed that we do not append the issuing item for certain cases, the behavior events are such a case (and the only one were we have to add such an exclusion, for now) > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2345) SelectOneChoiceRenderer doesn't render required attribute
[ https://issues.apache.org/jira/browse/TOBAGO-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2345. -- Fix Version/s: 5.13.1 6.5.1 Resolution: Fixed > SelectOneChoiceRenderer doesn't render required attribute > - > > Key: TOBAGO-2345 > URL: https://issues.apache.org/jira/browse/TOBAGO-2345 > Project: MyFaces Tobago > Issue Type: Bug >Affects Versions: 5.13.0, 6.5.0 >Reporter: Carsten Dimmek >Assignee: Henning Nöth >Priority: Trivial > Fix For: 5.13.1, 6.5.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878448#comment-17878448 ] Werner Punz edited comment on MYFACES-4679 at 9/2/24 5:27 AM: -- Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases. I have the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem, so that we can merge! FYI, the final fix is as I have proposed that we do not append the issuing item for certain cases, the behavior events are such a case (and the only one were we have to add such an exclusion, for now) was (Author: werpu): Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases, I get the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem we can merge! FYI, the final fix is as I have proposed that we do not append the issuing item for certain cases, the behavior events are such a case (and the only one were we have to add such an exclusion, for now) > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878448#comment-17878448 ] Werner Punz edited comment on MYFACES-4679 at 9/1/24 7:29 PM: -- Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases, I get the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem we can merge! FYI, the final fix is as I have proposed that we do not append the issuing item for certain cases, the behavior events are such a case (and the only one were we have to add such an exclusion, for now) was (Author: werpu): Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases, I get the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem we can merge! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878448#comment-17878448 ] Werner Punz commented on MYFACES-4679: -- Hi I have issued 3 preliminary merge requests, which restore the wanted behavior! https://github.com/apache/myfaces/pull/744 is the one for main Please review it whether it fixes it for your use cases, I get the appended example properly working again with it. Should the need arise, we can narrow down the append the issuing item even more by only executing that code on buttons hrefs and submits! But for now I will leave it as generic as is! [~volosied] please review it and if it solves your problem we can merge! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878332#comment-17878332 ] Melloware commented on MYFACES-4679: Sounds good to me. > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878329#comment-17878329 ] Werner Punz edited comment on MYFACES-4679 at 8/31/24 10:40 AM: I had to sleep over this to get some distance and my mind clear again (it was 2 am when I stopped working on this). I would propose following On the scripts side, I would remove the issuing element as key value pair for every case except for the case of triggering an action (click etc...) this can be done by simply checking whether an event is issued in combination and then checking which event and whitelist a click event for having the key value pair in! This should fix the issue for good while still retaining the original intention of 4606 of having the action element as key value pair in the request for action calls triggered via ajax which mimicks then the original submit behavior! If I follow this approach, I am rather confident that we will not have to fix anything on the Java side of things! Any objections? was (Author: werpu): I had to sleep over this to get some distance and my mind clear again (it was 2 am when I stopped working on this). I would propose following On the scripts side, I would remove the issuing element as key value pair for every case except for the case of triggering an action (click etc...) this can be done by simply checking whether an event is issued in combination and then checking which event and whitelist a click event for having the key value pair in! This should fix the issue for good while still retaining the original intention of 4606 of having the action element as key value pair in the request for action calls triggered via ajax which mimicks then the original submit behavior! If I follow this approach, I am rather confident that we do not have to fix anything on the java side of things! Any objections? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878329#comment-17878329 ] Werner Punz commented on MYFACES-4679: -- I had to sleep over this to get some distance and my mind clear again (it was 2 am when I stopped working on this). I would propose following On the scripts side, I would remove the issuing element as key value pair for every case except for the case of triggering an action (click etc...) this can be done by simply checking whether an event is issued in combination and then checking which event and whitelist a click event for having the key value pair in! This should fix the issue for good while still retaining the original intention of 4606 of having the action element as key value pair in the request for action calls triggered via ajax which mimicks then the original submit behavior! If I follow this approach, I am rather confident that we do not have to fix anything on the java side of things! Any objections? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878274#comment-17878274 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 11:47 PM: Ok full analysis: Following what happens is, that the code relies on a key value pair being present on a button to trigger an event. boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; HTMLButtonRenderBase!!! This works more or less for the normal submit as is, now in the ajax case this worked only because a second normal html request is triggered on top in this case which sends a normal submit! Given that both buttons are input type submit: 2 requests were triggered an ajax request and a normal submit. Now this worked on the old code more or less despite being a bug! By adding the key value pair we trigger the action code in HTMLButtonRendererBase and on top of that the buttons were issuing a normal request as well. Blur also added those key value pairs and hence suddenly we have an action and a blur being triggered despite only having blur. It is getting late/early here, so I have to postpone a possible solution! I also have to reread the ajax spec for this case, its been a while! was (Author: werpu): Ok full analysis: Following what happens is, that the code relies on a key value pair being present on a button to trigger an event. boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; HTMLButtonRenderBase!!! This works more or less for the normal submit as is, now in the ajax case this worked only because a second normal html request is triggered on top in this case which sends a normal submit! Given that both buttons are input type submit: 2 requests were triggered an ajax request and a normal submit. Now this worked on the old code more or less despite being a bug! By adding the key value pair we trigger the action code in HTMLButtonRendererBase and on top of that the buttons were issuing a normal request as well. Blur also added those key value pairs and hence suddenly we have an action and a blur being triggered despite only having blur. It is getting late/early here, so I have to postpone a possible solution! I also have to reread the ajax spec for this case, its been a while! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878274#comment-17878274 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 11:47 PM: Ok full analysis: Following what happens is, that the code relies on a key value pair being present on a button to trigger an event. boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; HTMLButtonRenderBase!!! This works more or less for the normal submit as is, now in the ajax case this worked only because a second normal html request is triggered on top in this case which sends a normal submit! Given that both buttons are input type submit: 2 requests were triggered an ajax request and a normal submit. Now this worked on the old code more or less despite being a bug! By adding the key value pair we trigger the action code in HTMLButtonRendererBase and on top of that the buttons were issuing a normal request as well. Blur also added those key value pairs and hence suddenly we have an action and a blur being triggered despite only having blur. It is getting late/early here, so I have to postpone a possible solution! I also have to reread the ajax spec for this case, its been a while! was (Author: werpu): Ok full analysis: Following what happens is, that the code relies on a key value pair being bresent on a button to trigger an event. boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; HTMLButtonRenderBase!!! This works more or less for the normal submit as is, now in the ajax case this worked only because a second normal html request is triggered in this case which sends a normal submit! Given that both buttons are input type submit: 2 requests were triggered an ajax request and a normal submit. Now this worked on the old code more or less despite being a bug! By adding the key value pair we trigger the action code in HTMLButtonRendererBase and on top of that the buttons were issuing a normal request as well. Blur also added those key value pairs and hence suddenly we have an action and a blur being triggered despite only having blur. It is getting late/early here, so I have to postpone a possible solution! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878274#comment-17878274 ] Werner Punz commented on MYFACES-4679: -- Ok full analysis: Following what happens is, that the code relies on a key value pair being bresent on a button to trigger an event. boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; HTMLButtonRenderBase!!! This works more or less for the normal submit as is, now in the ajax case this worked only because a second normal html request is triggered in this case which sends a normal submit! Given that both buttons are input type submit: 2 requests were triggered an ajax request and a normal submit. Now this worked on the old code more or less despite being a bug! By adding the key value pair we trigger the action code in HTMLButtonRendererBase and on top of that the buttons were issuing a normal request as well. Blur also added those key value pairs and hence suddenly we have an action and a blur being triggered despite only having blur. It is getting late/early here, so I have to postpone a possible solution! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878271#comment-17878271 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 11:19 PM: The issue is indeed in the HTMLButtonRendererBase: boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; isSubmitted is triggered no matter what and that code checks for a key which is identical to the button! The most likely fix is in the isSubmitted method! in case of pre 4606 this returned a false, in case of 4606 it returns true and hence triggers an action event at this stage was (Author: werpu): The issue is indeed in the HTMLButtonRendererBase: boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; isSubmitted is triggered no matter what and that code checks for a key which is identical to the button! in case of pre 4606 this returned a false, in case of 4606 it returns true and hence triggers an action event at this stage > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878271#comment-17878271 ] Werner Punz commented on MYFACES-4679: -- The issue is indeed in the HTMLButtonRendererBase: boolean activateActionEvent = !isReset(uiComponent) && isSubmitted(facesContext, uiComponent) && !disabled; isSubmitted is triggered no matter what and that code checks for a key which is identical to the button! in case of pre 4606 this returned a false, in case of 4606 it returns true and hence triggers an action event at this stage > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878268#comment-17878268 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 10:36 PM: Ok addendum. Not fixable on the client side, a simple button press causes 2 action events. What happens is that the added key:value pair simply triggers a normal action event just like it would come from the server. The second one is an ajax behavior event which has an action event added. The second one is probably the normal behavior we had for 4606, by added the key value pair we trigger basically the ajax and non ajax case. The server side code needs to be adapted that it does not go into the non ajax event case if we have an ajax request (this is detectable), to restore the pre 4606 behavior! The other solution would be to roll back 4606, but do we really want that? It was added to get a parameter parity between the non ajax and the ajax case for easier debugging and testing! was (Author: werpu): Ok addendum. Not fixable on the client side, a simple button press causes 2 action events. What happens is that the added key:value pair simply triggers a normal action event just like it would come from the server. The second one is an ajax behavior event which has an action event added. The second one is probably the normal behavior we had for 4606, by added the key value pair we trigger basically the ajax and non ajax case. The server side code needs to be adapted that it does not go into the non ajax event case if we have an ajax request (this is detectable), to restore the pre 4606 behavior! The other solution would be to roll back 4606, but do we really want that? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878268#comment-17878268 ] Werner Punz commented on MYFACES-4679: -- Ok addendum. Not fixable on the client side, a simple button press causes 2 action events. What happens is that the added key:value pair simply triggers a normal action event just like it would come from the server. The second one is an ajax behavior event which has an action event added. The second one is probably the normal behavior we had for 4606, by added the key value pair we trigger basically the ajax and non ajax case. The server side code needs to be adapted that it does not go into the non ajax event case if we have an ajax request (this is detectable), to restore the pre 4606 behavior! The other solution would be to roll back 4606, but do we really want that? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878267#comment-17878267 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 10:29 PM: Ok I have setup the example, took me a while, I had to port it to the jakarta namespace to get it working here: I can reproduce it... 4.0.2 und 4.0.1 seem to expose a correct behavior, the issue is indeed the issuing item appending. Here is a wild shot, the blur event appends also the name key value pair, we only should do that for submit cases not for blur or any other event), I guess. This should fix the issue. Maybe I can fix this on the client side only! I will give it a shot at the weekend! The server side code is correct here, because it does not have to deal with special events like blur, in case of non ajax cases! was (Author: werpu): Ok I have setup the example, took me a while, I had to port it to the jakarta namespace to get it working here: I can reproduce it... 4.0.2 und 4.0.1 seem to expose a correct behavior, the issue is indeed the issuing item appending. Here is a wild shot, the blur event appends also the name key value pair, we only should do that for submit cases not for blur or any other event), I guess. This should fix the issue. Maybe I can fix this on the client side only! I will give it a shot at the weekend! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878267#comment-17878267 ] Werner Punz edited comment on MYFACES-4679 at 8/30/24 10:28 PM: Ok I have setup the example, took me a while, I had to port it to the jakarta namespace to get it working here: I can reproduce it... 4.0.2 und 4.0.1 seem to expose a correct behavior, the issue is indeed the issuing item appending. Here is a wild shot, the blur event appends also the name key value pair, we only should do that for submit cases not for blur or any other event), I guess. This should fix the issue. Maybe I can fix this on the client side only! I will give it a shot at the weekend! was (Author: werpu): Ok I have setup the example: I can reproduce it... 4.0.2 und 4.0.1 seem to expose a correct behavior, the issue is indeed the issuing item appending. Here is a wild shot, the blur event appends also the name key value pair, we only should do that for submit cases not for blur or any other event), I guess. This should fix the issue. Maybe I can fix this on the client side only! I will give it a shot at the weekend! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878267#comment-17878267 ] Werner Punz commented on MYFACES-4679: -- Ok I have setup the example: I can reproduce it... 4.0.2 und 4.0.1 seem to expose a correct behavior, the issue is indeed the issuing item appending. Here is a wild shot, the blur event appends also the name key value pair, we only should do that for submit cases not for blur or any other event), I guess. This should fix the issue. Maybe I can fix this on the client side only! I will give it a shot at the weekend! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878262#comment-17878262 ] Werner Punz commented on MYFACES-4679: -- Ok took me a while to set it up, we have indeed a problem here a) 4.0.1 works properly like expected b) 4.0.2 onwards trigger the issue and also issue 2 actions! The patch indeed causes an action to be triggered on a blur event! I will look into the root cause of this! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877869#comment-17877869 ] Werner Punz edited comment on MYFACES-4679 at 8/29/24 7:01 PM: --- Ok I finally had time to read this, in my opinion the following behavior should be correct a) Click move out release should not trigger anything at all b) Click on the second button release move click out only the blur event should occur. a) should not trigger a request at all (or one where nothing happens) b) should trigger a request but only with blur being handled! I will look at the example tomorrow and will try to figure it out on the code side! was (Author: werpu): Ok I finally had time to read this, in my opinion the following behavior should be correct a) Click move out release should not trigger anything at all b) Click on the second button release move click out only the blur event should occur. a) should not trigger a request at all (or one where nothing happens) b) should trigger a request but only with blur being handled! I will look at the example tomorrow and will try to figure it out on the code side! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877869#comment-17877869 ] Werner Punz commented on MYFACES-4679: -- Ok I finally had time to read this, in my opinion the following behavior should be correct a) Click move out release should not trigger anything at all b) Click on the second button release move click out only the blur event should occur. a) should not trigger a request at all (or one where nothing happens) b) should trigger a request but only with blur being handled! I will look at the example tomorrow and will try to figure it out on the code side! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877750#comment-17877750 ] Volodymyr Siedlecki commented on MYFACES-4679: -- You are correct about MyFaces - 2.3.10 doesn't invoke the action when blur occurs (only the listener), but 2.3.11 (with 4606) invokes both. I just tested Mojarra and found the following behaviors when the blur event is triggered: 2.2.20: - Only the ajaxEventBean.listener() is triggered 2.3.21: - Both ajaxEventBean.listener() and ajaxEventBean.confirm() are triggered Both: - Only 1 XHR request is sent - Issuing element is not attached I'm curious what changed in the RI to trigger the confirm action? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877729#comment-17877729
]
Thomas Andraschko edited comment on MYFACES-4679 at 8/29/24 2:36 PM:
-
AFAIR Mojarra behaves like this:
onBlur both listener & actionListener is called, only 1 ajax request is done.
so the question is more a spec question:
{code:xml}
{code}
should it invoke the action or not onBlur?
As far as i understand you: 2.3.10 does NOT invoke the action, 2.3.11 does.
was (Author: tandraschko):
AFAIR Mojarra behaves like this:
onBlur both listener & actionListener is called, only 1 ajax request is done.
so the question is more a spec question:
{code:xml}
{code}
should it invoke the action or not onBlur?
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877729#comment-17877729
]
Thomas Andraschko commented on MYFACES-4679:
AFAIR Mojarra behaves like this:
onBlur both listener & actionListener is called, only 1 ajax request is done.
so the question is more a spec question:
{code:xml}
{code}
should it invoke the action or not onBlur?
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877722#comment-17877722 ] Volodymyr Siedlecki commented on MYFACES-4679: -- Thanks again. Reverting would be a last resort. I created a pull request and I think my second commit might a potential solution. Otherwise, perhaps we need to open up a spec issue here? Would appreciate your feedback. Thanks as always! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877520#comment-17877520 ] Werner Punz edited comment on MYFACES-4679 at 8/29/24 7:44 AM: --- Sorry for the delay, I have been busy in my sparetime with 4676 which I have resolved tonight, I will start to investigate this issue tomorrow! I would not revert 4606 because it was added for a reason, probably the best fix would be to adapt the decode method accordingly to deal with this! Adding additional behaviors for our implementation of faces.js wont break the code of other frameworks which have their own faces.js implementation we just have to make sure that it does not replace the existing behavior just that it augments it! But as I said I will look tonight deeper into it! was (Author: werpu): Sorry for the delay, I have been busy in my sparetime with 4676 which I have resolved tonight, I will start to investigate this issue tomorrow! I would not revert 4606 because it was added for a reason, probably the best fix would be to adapt the decode method accordingly to deal with this! Adding additional behaviors for our implementation of faces.js wont break the code of other frameworks which have their own faces.js implementation we just have to make sure that it does not replace the existing behavior just that it augments it! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877520#comment-17877520 ] Werner Punz edited comment on MYFACES-4679 at 8/29/24 7:44 AM: --- Sorry for the delay, I have been busy in my sparetime with 4676 which I have resolved tonight, I will start to investigate this issue tomorrow! I would not revert 4606 because it was added for a reason, probably the best fix would be to adapt the decode method accordingly to deal with this! Adding additional behaviors for our implementation of faces.js wont break the code of other frameworks which have their own faces.js implementation we just have to make sure that it does not replace the existing behavior just that it augments it! was (Author: werpu): Sorry for the delay, I have been busy in my sparetime with 4676 which I have resolved tonight, I will start to investigate this issue tomorrow! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877520#comment-17877520 ] Werner Punz commented on MYFACES-4679: -- Sorry for the delay, I have been busy in my sparetime with 4676 which I have resolved tonight, I will start to investigate this issue tomorrow! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
