-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FormData.constructor: implement optional submitter parameter #3496
Conversation
9cc795e
to
197685a
Compare
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was not compliant with the spec or browsers, as elements
excludes Image Buttons
Going to pull some of this out into a separate PR to improve CSSOM coordinates |
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.
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.
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.
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.
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
197685a
to
ab53858
Compare
|
||
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a test (passes in jsdom and Chrome/Webkit; fails in Firefox since it seems to only set the coordinate for native events)
a52786f
to
ee5a9e5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for taking so long to review this, especially given all the prerequisite work you did. It's great!
Add support for the new optional
submitter
parameter to theFormData
constructor. 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: