[wdspec] add network interception invalidation tests for all remaining methods#42667
[wdspec] add network interception invalidation tests for all remaining methods#42667
Conversation
fb2fcbd to
aa4bba2
Compare
304dfa0 to
177e311
Compare
aa4bba2 to
a97349b
Compare
df14886 to
d09d5bd
Compare
|
Note the TODOs: Because we are type-annotating everything, these will require extra work. Deferring them to another PR. |
ad8f6fe to
a884b62
Compare
juliandescottes
left a comment
There was a problem hiding this comment.
Looks good thanks! I need to take another look, but sharing some comments for now
|
Noticed another issue in continue_with_auth when adding "valid" tests locally. The credentials should be in a separate object. Instead they were at the top level of the command params. Re-flagging for review. |
|
@sadym-chromium would you take this PR over? |
yes, thanks! |
| await fetch(text_url) | ||
|
|
||
| response_completed_event = await wait_for_future_safe(on_response_completed) | ||
| response_completed_event = await on_response_completed |
There was a problem hiding this comment.
Could this change maybe be the reason why the wpt.fyi results show a timeout for this test file now with Chrome?
There was a problem hiding this comment.
No, the job seems to timeout on the invalid phase test.
The spec is quite clear about the fact that this should be an error:
If phase is "authRequired", then return error with error code invalid argument.
But even if they don't implement the phase check this shouldn't timeout.
Chrome also seems to timeout on various other tests:
- continue_with_auth/invalid.py::test_params_request_invalid_phase[responseStarted]
- continue_response/invalid.py::test_params_reason_phrase_invalid_type[False]
All those tests have in common that they need to block a request in another phase than "beforeRequest". I remember that during the initial review of this patch, I requested several times to change the phase of tests from "beforeRequest" to the appropriate phase but this was not addressed, so it's possible that chrome doesn't support blocking the request in phases after "beforeRequest".
Looking at wpt.fyi for other intercept test, my guess is that chrome is always adding intercepts in the beforeRequest phase, even if you are specifying another phase. This would be enough to make the setup_blocked_request helper timeout.
cc @sadym-chromium can you confirm or tell me where the code handling intercepts is located so that I can check?
There was a problem hiding this comment.
Unfortunately, for now our network interception implementation is racy and sometimes hangs forever. We are working on fixing it.
There was a problem hiding this comment.
Wait. This test does not set interceptions, so it should work just fine. Let me check.
There was a problem hiding this comment.
Sorry it's a bit misleading :)
The question from @whimboo was added for this test (test_params_request_no_such_request), but the actual timeout happens in test_params_request_invalid_phase (right above this one) which indirectly uses add_intercept via setup_blocked_request
whimboo
left a comment
There was a problem hiding this comment.
Thanks @juliandescottes. From my point of view this looks good now.
When merging it upstream we might have to wait for the next downstream sync. Maybe we can land on mozilla-central and then upstream sync, which is clearly faster?
That would work for me. @sadym-chromium any objection or additional review feedback ? |
|
Thanks for the review, pushed on phabricator at https://phabricator.services.mozilla.com/D196424 FYI. |
…g methods Synced from #42667 Differential Revision: https://phabricator.services.mozilla.com/D196424 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1870032 gecko-commit: d3a29d02b3dd8d8cfbfff6fcad00d94226e102e8 gecko-reviewers: webdriver-reviewers, whimboo
|
This is now a duplicate of #43688 , closing. |
…r all remaining methods r=webdriver-reviewers,whimboo Synced from web-platform-tests/wpt#42667 Differential Revision: https://phabricator.services.mozilla.com/D196424
…g methods Synced from #42667 Differential Revision: https://phabricator.services.mozilla.com/D196424 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1870032 gecko-commit: d3a29d02b3dd8d8cfbfff6fcad00d94226e102e8 gecko-reviewers: webdriver-reviewers, whimboo
…r all remaining methods r=webdriver-reviewers,whimboo Synced from web-platform-tests/wpt#42667 Differential Revision: https://phabricator.services.mozilla.com/D196424 UltraBlame original commit: d3a29d02b3dd8d8cfbfff6fcad00d94226e102e8
…r all remaining methods r=webdriver-reviewers,whimboo Synced from web-platform-tests/wpt#42667 Differential Revision: https://phabricator.services.mozilla.com/D196424 UltraBlame original commit: d3a29d02b3dd8d8cfbfff6fcad00d94226e102e8
…r all remaining methods r=webdriver-reviewers,whimboo Synced from web-platform-tests/wpt#42667 Differential Revision: https://phabricator.services.mozilla.com/D196424 UltraBlame original commit: d3a29d02b3dd8d8cfbfff6fcad00d94226e102e8
…r all remaining methods r=webdriver-reviewers,whimboo Synced from web-platform-tests/wpt#42667 Differential Revision: https://phabricator.services.mozilla.com/D196424
…g methods Synced from #42667 Differential Revision: https://phabricator.services.mozilla.com/D196424 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1870032 gecko-commit: d3a29d02b3dd8d8cfbfff6fcad00d94226e102e8 gecko-reviewers: webdriver-reviewers, whimboo
fail request(previously added)continue requestcontinue responseprovide responsecontinue with auth