-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
html, xhr: Add tests for 'formdata' event #14637
Conversation
Taskcluster failures don't look related to this PR. |
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.
idlharness test changes LGTM
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 looks fine to me, but per the HTML review we'll need to test the event constructor as well.
const waitForLoad = new Promise(resolve => { addEventListener('load', resolve); }) | ||
|
||
idl_test( | ||
['html'], | ||
['SVG', 'cssom', 'touch-events', 'uievents', 'dom'], | ||
['SVG', 'cssom', 'touch-events', 'uievents', 'dom', 'xhr'], |
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.
Isn't the interface added to HTML?
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.
Yes. However 'xhr' is necessary for FormData interface dependency.
(I suspect you might be able to address the Taskcluster failure by rebasing on master. Apparently something changed over the holidays. Happy new year btw!) |
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.
I'll land this when the specification PR is ready.
ea3a519
to
08450ab
Compare
I ran
to see if I can get Taskcluster to pass. |
Taskcluster failures are for known flaky tests. |
- Add formdata event and FormDataEvent interface - Fire it in "constructing the entry list" algorithm - Introduce "constructing entry list" flag of a form element to avoid recursive submission. Tests: web-platform-tests/wpt#14637. Change to XMLHttpRequest: whatwg/xhr#231. This fixes a part of WICG/webcomponents#187.
The test was upstreamed to WPT by web-platform-tests/wpt#14637 Bug: 825684 Change-Id: I66ef778831adebfccf67fc9e68f94e81206f9380 Reviewed-on: https://chromium-review.googlesource.com/c/1405165 Reviewed-by: Yoshifumi Inoue <yosin@chromium.org> Commit-Queue: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/master@{#622789}
- Add formdata event and FormDataEvent interface - Fire it in "constructing the entry list" algorithm - Introduce "constructing entry list" flag of a form element to avoid recursive submission. Tests: web-platform-tests/wpt#14637. Change to XMLHttpRequest: whatwg/xhr#231. This fixes a part of WICG/webcomponents#187.
- Add formdata event and FormDataEvent interface - Fire it in "constructing the entry list" algorithm - Introduce "constructing entry list" flag of a form element to avoid recursive submission. Tests: web-platform-tests/wpt#14637. Change to XMLHttpRequest: whatwg/xhr#231. This fixes a part of WICG/webcomponents#187.
didCallHandler = true; | ||
}); | ||
new FormData(form); | ||
assert_true(didCallHandler); |
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.
Same as above, I guess... I'm reading this section:
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#constructing-form-data-set:formdataevent
And the event fires as normal, and bubbles = false
per the EventInit
dict.
This is a follow-up of whatwg#4239, and fixes an issue pointed out in web-platform-tests/wpt#14637
This is a follow-up of #4239, and fixes an issue pointed out in web-platform-tests/wpt#14637.
This fixes a part of WICG/webcomponents#187
HTML specification PR: whatwg/html#4239
XHR specification PR: whatwg/xhr#231