FormData.constructor: implement optional submitter parameter #3496
Conversation
This file contains 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
This was referenced Jan 12, 2023
jenseng
force-pushed
the
form-data-submitter
branch
from
9cc795e
to
197685a
Compare
jenseng
changed the title
jenseng
commented
Feb 17, 2023
jenseng
commented
Feb 17, 2023
| @@ -96,7 +109,7 @@ function constructTheEntryList(form, submitter) { | |||
| // TODO: handle encoding | |||
| // TODO: handling "constructing entry list" | |||
|
|
|||
| const controls = form.elements.filter(isSubmittable); // submittable is a subset of listed | |||
There was a problem hiding this comment.
This was not compliant with the spec or browsers, as elements excludes Image Buttons
jenseng
commented
Mar 2, 2023
|
Going to pull some of this out into a separate PR to improve CSSOM coordinates |
jenseng
added a commit
to jenseng/jsdom
that referenced
this pull request
Mar 2, 2023
Ensure that they correctly reflect the coordinate relative to the origin of the window at the time of init (i.e. `clientX/Y` plus `scrollX/Y`). We record it during init, since during scrollX/Y may have change and result in the wrong `pageX/Y` values; see added tuWPT. Also track the target-relative coordinate during init (still just `(0, 0)` in the absence of layout support). This doesn't fundamentally change any behavior, but makes the implementation more future proof, making it safer to start handling Image Button submitters when constructing the form data set; see jsdom#3496 where this code was extracted from.
jenseng
added a commit
to jenseng/jsdom
that referenced
this pull request
Mar 2, 2023
Ensure that they correctly reflect the coordinate relative to the origin of the window at the time of init (i.e. `clientX/Y` plus `scrollX/Y`). We record it during init, since during scrollX/Y may have change and result in the wrong `pageX/Y` values; see added tuWPT. Also track the target-relative coordinate during init (still just `(0, 0)` in the absence of layout support). This doesn't fundamentally change any behavior, but makes the implementation more future proof, making it safer to start handling Image Button submitters when constructing the form data set; see jsdom#3496 where this code was extracted from.
jenseng
added a commit
to jenseng/jsdom
that referenced
this pull request
Mar 2, 2023
Ensure that `pageX/Y` reflect the coordinate relative to the origin of the window at the time of init (i.e. `clientX/Y` plus `scrollX/Y`). We record it during init, since `scrollX/Y` may change, which could result in the wrong `pageX/Y` values; see added tuWPT. Also track the target-relative coordinate during init (still just `(0, 0)` in the absence of layout support). This doesn't fundamentally change any behavior, but makes the implementation more future proof, making it safer to start handling Image Button submitters when constructing the form data set; see jsdom#3496 where this code was extracted from.
jenseng
added a commit
to jenseng/jsdom
that referenced
this pull request
Mar 2, 2023
Ensure that `pageX/Y` reflect the coordinate relative to the origin of the window at the time of init (i.e. `clientX/Y` plus `scrollX/Y`). We record it during init, since `scrollX/Y` may change, which could result in the wrong `pageX/Y` values; see added tuWPT. Also track the target-relative coordinate during init (still just `(0, 0)` in the absence of layout support). This doesn't fundamentally change any behavior, but makes the implementation more future proof, making it safer to start handling Image Button submitters when constructing the form data set; see jsdom#3496 where this code was extracted from.
jenseng
added a commit
to jenseng/jsdom
that referenced
this pull request
Mar 12, 2023
Ensure that `pageX/Y` reflect the coordinate relative to the origin of the window at the time of init (i.e. `clientX/Y` plus `scrollX/Y`). We record it during init, since `scrollX/Y` may change, which could result in the wrong `pageX/Y` values; see added tuWPT. Also track the target-relative coordinate during init (still just `(0, 0)` in the absence of layout support). This doesn't fundamentally change any behavior, but makes the implementation more future proof, making it safer to start handling Image Button submitters when constructing the form data set; see jsdom#3496 where this code was extracted from.
In order to fully support it, this requires more robust Image Button support (i.e. track selected coordinate, use when constructing form data set). This feature is implemented in the latest versions of Chrome/Firefox/ Safari, where the newly enabled WPTs are also passing. Spec: https://xhr.spec.whatwg.org/#interface-formdata Spec PR: whatwg/xhr#366
jenseng
force-pushed
the
form-data-submitter
branch
from
197685a
to
ab53858
Compare
jenseng
commented
Apr 11, 2023
|
|
||
| // TODO: if/when layout is implemented, record the selected coordinate at the start of dispatch and use it here, | ||
| // rather than relying on these getters that just mirror pageX/Y outside of dispatch | ||
| this._selectedCoordinate = { x: event.offsetX, y: event.offsetY }; |
There was a problem hiding this comment.
While it would be simpler to just always use (0, 0) (which would be fine for a synthetic .click() of the button), this can give us parity with Chrome/WebKit when a coordinate is actually selected, despite the lack of layout support. Thinking about it some more though, I should really add a new test around the non-zero case (the upstream WPTs only do synthetic clicks)
LMK if you have other suggestions/thoughts around making this more clear in the code/comments
There was a problem hiding this comment.
Added a test (passes in jsdom and Chrome/Webkit; fails in Firefox since it seems to only set the coordinate for native events)
jenseng
force-pushed
the
form-data-submitter
branch
from
a52786f
to
ee5a9e5
Compare
domenic
approved these changes
May 27, 2023
This was referenced May 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Add support for the new optional
submitterparameter to theFormDataconstructor. This feature is implemented in the latest versions of Chrome/Firefox/Safari.Spec: https://xhr.spec.whatwg.org/#interface-formdata
Spec PR: whatwg/xhr#366
In order to fully implement it in jsdom, this requires more robust Image Button support (i.e. track selected coordinate, use when constructing form data set).
Testing notes: