1661440 - New wpt failures in /html/cross-origin-embedder-policy/header-parsing.https.html

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Syncing wpt PR 20852 found new untriaged test failures in CI

Tests Affected

Firefox-only failures

/html/cross-origin-embedder-policy/header-parsing.https.html: TIMEOUT
navigation allowed for ["require-corp",""]: NOTRUN
navigation allowed for ["","require-corp"]: TIMEOUT

CI Results

Missing results from treeherder
GitHub PR Head

Notes

These updates will be on mozilla-central once bug 1604915 lands.

Note: this bug is for tracking fixing the issues and is not
owned by the wpt sync bot.

This bug is linked to the relevant tests by an annotation in
https://github.com/web-platform-tests/wpt-metadata. These annotations
can be edited using the wpt interop dashboard
https://jgraham.github.io/wptdash/

If this bug is split into multiple bugs, please also update the
annotations, otherwise we are unable to track which wpt issues are
already triaged. Resolving as duplicate or closing this issue should
be cause the bot to automatically update or remove the annotation.

Comment 2

[Anne (:annevk)]

It does seem like there's still a failure here of sorts. At least the page is timing out for me 15 tests in on Nightly. Weirdly enough https://wpt.fyi/ says there's no problem.

Comment 3

[Valentin Gosu [:valentin] {{ PTO 2 - 12 April }}]

I think this is because we don't fire the onload handler for navigations that fail due to COEP (should we?)

If I add a t.step_timeout(resolve, 1000); there, then it all works - with the exception of the ['', 'require-corp'] and ['require-corp', ''] testcases. I'll have to look into that. I assume it's due to how we merge duplicated headers.

Comment 4

[Valentin Gosu [:valentin] {{ PTO 2 - 12 April }}]

Attachment: Bug 1661440 - Call resolve after timeout expires in header-parsing.https.html r=annevk

In Firefox we don't call onload for failed CORP-COEP navigations (maybe we should?)
In this case, to make sure the test fully runs, we add a timeout that resolves the promise
after one second.

Comment 5

[Anne (:annevk)]

Thanks for getting to the root cause. If that's all there is to it, let's fix bug 1663633 and leave this be.