Conversation
An AjaxFormSubmitBehavior whose shouldTriggerJavaScriptSubmitEvent() returns true fires a submit event on the form before its Ajax request, so that submit handlers run - UploadProgressBar starts its bar from one. Since the jQuery-free engine, the precondition fired it with dispatchEvent(). Firefox still submits a form for a submit event fired by a script unless the event is cancelled, so an AjaxButton like the one of the upload example sent its Ajax request and submitted the form the normal way as well: the page was reloaded behind the Ajax response. Chrome does not submit for such an event. The precondition now calls the new Wicket.Event.triggerSubmit(form) of both engines. It fires the event, tells whether a submit handler cancelled it, and cancels it once it has bubbled up to the window, so no browser submits the form; the Ajax request does. A handler cancelling the event still stops the request. Applications see the Ajax request only, as in Chrome. Wicket 10.x is not affected: its precondition triggers the event through jQuery and cancels it. GitHub issue #1650
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1651 +/- ##
=========================================
Coverage 61.95% 61.95%
- Complexity 11280 11281 +1
=========================================
Files 1250 1250
Lines 48429 48429
Branches 6792 6792
=========================================
+ Hits 30002 30006 +4
+ Misses 15729 15726 -3
+ Partials 2698 2697 -1 🚀 New features to boost your workflow:
|
Contributor
|
I'm looking at this PR, and it seems its not correct yet. The main issue is an event that never reaches window because of stopPropagation(). |
Contributor
Author
Maybe. I just found this while working on #1637 |
…ner URL Wicket.Event.triggerSubmit() cancelled the submit event from a listener on the window. A handler that stopped the propagation, or a form in a shadow root, kept the event from getting there, so it stayed uncancelled and Firefox still submitted the form besides the Ajax request. The listener on the window also cancelled a submit event triggered from inside a submit handler, so the inner call reported a cancellation that no handler made. The event is now cancelled by a listener added last on the form itself, as the jQuery code before the jQuery-free engine did, and when a handler stops its immediate propagation. Only a capturing handler stopping the event before it reaches the form still lets Firefox submit. A handler on the form, or one capturing the event on its way there, can cancel the Ajax request. Handlers above the form see the event cancelled already, so a document level listener can no longer stop the Ajax request, as before the jQuery-free engine. Form.getJsForListenerUrl() fired a submit event through Wicket.Event.fire() to submit the form. With the jQuery-free engine that is a plain dispatchEvent(), for which Chrome never submits a form, so a FormComponentUpdatingBehavior did nothing in Chrome. It now calls triggerSubmit() and submits the form unless a handler cancelled the event, in both engines, which is what jQuery's trigger() did. Listeners added with addEventListener() now see that event with the jQuery engine too. SubmitEventSeleniumTest drives the Ajax upload and form input examples with both engines, and can run in Firefox or on a Selenium grid. GitHub issue #1650 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1650.
An
AjaxFormSubmitBehaviorwhoseshouldTriggerJavaScriptSubmitEvent()returnstruefires asubmitevent on the form before its Ajax request (UploadProgressBarstarts its bar from it). Since the jQuery-free engine (615af3e) the precondition fires it withdispatchEvent(). Firefox still submits a form for a submit event fired by a script unless the event is cancelled, so in Firefox the button sent its Ajax request and submitted the form normally, reloading the page behind the Ajax response. Chrome does not submit for such an event.The precondition now calls a new
Wicket.Event.triggerSubmit(form), in bothwicket-ajax-jquery.jsandwicket-ajax.js. It fires the event, tells whether a submit handler cancelled it, and cancels it once it has bubbled up to the window, so no browser submits the form. A handler cancelling the event still stops the Ajax request.Master only: Wicket 10.x triggers the event through jQuery and cancels it in its own handler, and was checked in Firefox not to submit.
Tests:
Wicket.Event.triggerSubmit(4 tests inevent.js), run in Chrome and Firefox with both engines.AjaxFormSubmitBehaviorTest.theSubmitEventIsTriggeredWithoutSubmittingTheForm.