[
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}
<div>
<h:outputText value="#{helloBean.hello}" />
<h:inputText />
<h:commandLink id="confirm" value="listner1"
action="#{ajaxEventBean.confirm()}" >
<f:ajax event="blur"/>
</h:commandLink>
</div>
<div>
<h:inputText />
<h:commandLink id="confirm2" value="listner2"
action="#{ajaxEventBean.confirm()}" >
<f:ajax event="click" listener="#{ajaxEventBean.listener()}"></f:ajax>
</h:commandLink>
<h:commandLink id="confirm3" value="listner3"
action="#{ajaxEventBean.confirm()}" >
<f:ajax event="click" execute="@none" />
</h:commandLink>
{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}
<div>
<h:outputText value="#{helloBean.hello}" />
<h:inputText />
<h:commandLink id="confirm" value="listner1"
action="#{ajaxEventBean.confirm()}" >
<f:ajax event="blur"/>
</h:commandLink>
</div>
<div>
<h:inputText />
<h:commandLink id="confirm2" value="listner2"
action="#{ajaxEventBean.confirm()}" >
<f:ajax event="click" listener="#{ajaxEventBean.listener()}"></f:ajax>
</h:commandLink>
<h:commandLink id="confirm3" value="listner3"
action="#{ajaxEventBean.confirm()}" >
<f:ajax event="click" execute="@none" />
</h:commandLink>
{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)
