Support DOM eager evaluation allowlist in worker
Categories
(DevTools :: Console, defect)
Tracking
(firefox-esr102 unaffected, firefox113 wontfix, firefox114 wontfix, firefox115 fixed)
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox113 | --- | wontfix |
| firefox114 | --- | wontfix |
| firefox115 | --- | fixed |
People
(Reporter: arai, Assigned: arai)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(4 files)
In bug 1806598, we're going to apply eager evaluation allowlist also to getter calls, instead of treating all getter calls side-effect-free.
Then, we don't support DOM allowlist in worker because we generate the allowlist from sandbox, which is not available on worker thread.
which means all DOM getters are blocked in eager evaluation.
There was one testcase which relied on the DOM getters in worker:
setInputValue(hud, "globalThis.location.href");
...
await waitFor(() =>
evaluationContextSelectorButton.innerText.includes(workerFile)
);
This requires adding WorkerGlobalScope and WorkerLocation getters into allowlist.
(For now, I'm going to modify the testcase not to rely on DOM getters in eager evaluation)
Then, in order to support eager-evaluation allowlist in worker, we need a way to generate the allowlist without creating sandbox.
Possible solution I can think of is to create ChromeUtils method that takes a function and checks if the function is side-effect-free.
That means, move the allowlist creation and check from devtools JS code to native ChromeUtils method.
ChromeUtlls is accessible also on worker thread, and comparing native function pointer and JSJitInfo pointer doesn't require creating objects.
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 1•2 years ago
|
||
Depends on D175088
| Assignee | ||
Comment 2•2 years ago
|
||
Depends on D175089
| Assignee | ||
Comment 3•2 years ago
|
||
Depends on D175090
| Assignee | ||
Comment 4•2 years ago
|
||
Depends on D175091
Comment 5•2 years ago
|
||
Thanks a lot arai for working on this. I have positive feedback on the whole patch stack, so feel free to put them in review so I can have a thorough look :)
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 6•2 years ago
|
||
The current patch queue seems to fix both bug 1818180 and bug 1822662. Should we resolve them as duplicated bugs?
Comment 10•2 years ago
|
||
The following field has been copied from duplicate bugs:
| Field | Value | Source |
|---|---|---|
| Regressed by | bug 1806598 | bug 1818180 and bug 1822662 |
For more information, please visit BugBot documentation.
Comment 11•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/37482f544447
https://hg.mozilla.org/mozilla-central/rev/58a13013137a
https://hg.mozilla.org/mozilla-central/rev/2dd3c94ff852
https://hg.mozilla.org/mozilla-central/rev/e69bb7d10d11
Comment 12•2 years ago
|
||
Set release status flags based on info from the regressing bug 1806598
Updated•2 years ago
|
Comment 13•2 years ago
|
||
The patch landed in nightly and beta is affected.
:arai, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox114towontfix.
For more information, please visit BugBot documentation.
Updated•2 years ago
|
Description
•