RESOLVED FIXED Bug 194366
Unable to sign in leetcode
https://bugs.webkit.org/show_bug.cgi?id=194366
Summary Unable to sign in leetcode
youenn fablet
Reported 2019-02-06 16:06:56 PST
Test that Request constructor throws if FetchRequestInit.signal is not undefined, null or an AbortSignal object
Attachments
Patch (7.40 KB, patch)
2019-02-06 16:12 PST, youenn fablet
no flags
Patch (7.38 KB, patch)
2019-02-06 16:23 PST, youenn fablet
no flags
Patch (7.48 KB, patch)
2019-02-06 16:56 PST, youenn fablet
no flags
Archive of layout-test-results from ews101 for mac-highsierra (2.45 MB, application/zip)
2019-02-06 18:01 PST, EWS Watchlist
no flags
Archive of layout-test-results from ews104 for mac-highsierra-wk2 (2.80 MB, application/zip)
2019-02-06 18:02 PST, EWS Watchlist
no flags
Patch (7.85 KB, patch)
2019-02-06 18:23 PST, youenn fablet
no flags
Archive of layout-test-results from ews123 for ios-simulator-wk2 (2.40 MB, application/zip)
2019-02-06 20:07 PST, EWS Watchlist
no flags
youenn fablet
Comment 1 2019-02-06 16:12:17 PST
youenn fablet
Comment 2 2019-02-06 16:23:04 PST
youenn fablet
Comment 3 2019-02-06 16:56:15 PST
EWS Watchlist
Comment 4 2019-02-06 18:01:32 PST
Comment on attachment 361346 [details] Patch Attachment 361346 [details] did not pass mac-ews (mac): Output: https://webkit-queues.webkit.org/results/11059517 New failing tests: imported/w3c/web-platform-tests/fetch/api/abort/general.any.html imported/w3c/web-platform-tests/fetch/api/abort/general.any.worker.html
EWS Watchlist
Comment 5 2019-02-06 18:01:34 PST
Created attachment 361355 [details] Archive of layout-test-results from ews101 for mac-highsierra The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-highsierra Platform: Mac OS X 10.13.6
EWS Watchlist
Comment 6 2019-02-06 18:02:36 PST
Comment on attachment 361346 [details] Patch Attachment 361346 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/11059496 New failing tests: imported/w3c/web-platform-tests/fetch/api/abort/general.any.html imported/w3c/web-platform-tests/fetch/api/abort/general.any.worker.html
EWS Watchlist
Comment 7 2019-02-06 18:02:38 PST
Created attachment 361356 [details] Archive of layout-test-results from ews104 for mac-highsierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-highsierra-wk2 Platform: Mac OS X 10.13.6
youenn fablet
Comment 8 2019-02-06 18:23:49 PST
EWS Watchlist
Comment 9 2019-02-06 20:07:20 PST
Comment on attachment 361359 [details] Patch Attachment 361359 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: https://webkit-queues.webkit.org/results/11060506 New failing tests: fast/viewport/ios/device-width-viewport-after-changing-view-scale.html
EWS Watchlist
Comment 10 2019-02-06 20:07:22 PST
Created attachment 361372 [details] Archive of layout-test-results from ews123 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews123 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.6
Chris Dumez
Comment 11 2019-02-07 11:43:11 PST
Comment on attachment 361359 [details] Patch r=me
Alex Christensen
Comment 12 2019-02-07 11:46:27 PST
Comment on attachment 361359 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=361359&action=review r=me Should we propose a loosening change to the fetch spec, or should we indicate that we intend to change this back once the web has updated their polyfills? > LayoutTests/http/wpt/fetch/request-abort-expected.txt:5 > +FAIL Request from URL with signal assert_throws: function "() => { new Request("/", {signal: "my signal"}) }" did not throw > +FAIL Request from request with signal assert_throws: function "() => { new Request(request, {signal: "my signal"}) }" did not throw These tests should probably not print "FAIL" which indicates that there is something yet to fix.
youenn fablet
Comment 13 2019-02-07 11:49:48 PST
Thanks for the reviews. (In reply to Alex Christensen from comment #12) > Comment on attachment 361359 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=361359&action=review > > r=me > Should we propose a loosening change to the fetch spec, or should we > indicate that we intend to change this back once the web has updated their > polyfills? We intend to revert these changes whenever possible. I'll file a Bugzilla accordingly. > > LayoutTests/http/wpt/fetch/request-abort-expected.txt:5 > > +FAIL Request from URL with signal assert_throws: function "() => { new Request("/", {signal: "my signal"}) }" did not throw > > +FAIL Request from request with signal assert_throws: function "() => { new Request(request, {signal: "my signal"}) }" did not throw > > These tests should probably not print "FAIL" which indicates that there is > something yet to fix. The idea is to keep the test as is and rebase the test expectation once the C++ changes are reverted.
WebKit Commit Bot
Comment 14 2019-02-07 12:15:03 PST
Comment on attachment 361359 [details] Patch Clearing flags on attachment: 361359 Committed r241137: <https://trac.webkit.org/changeset/241137>
WebKit Commit Bot
Comment 15 2019-02-07 12:15:05 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 16 2019-02-07 12:16:30 PST
Note You need to log in before you can comment on or make changes to this bug.