Fix test_ext_userScripts_register.js with parent-controlled navigation
Categories
(WebExtensions :: General, task, P3)
Tracking
(firefox105 fixed)
Tracking | Status | |
---|---|---|
firefox105 | --- | fixed |
People
(Reporter: mccr8, Assigned: mccr8)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
When parent controlled navigation is enabled, this XPCShell test fails in automation, about 40% of the time.
The failure is:
xpcshell-remote.ini:toolkit/components/extensions/test/xpcshell/test_ext_userScripts_register.js | test_userscripts_register_cookieStoreId - [test_userscripts_register_cookieStoreId : 119] Expected textContent on content page - "" == "private"
I think this means that the web extension content script that is supposed to run on the page that is opened with private browsing (because it matches "firefox-private") fails to run, so it ends up with the unmodified page and returns "" instead of the expected "private".
If I run this test locally with --verify and Fission enabled, I get different failures, but I haven't managed to reproduce the private browsing failure yet. I'll have to see if Anny fixed other tests related to private browsing before.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Bug 1763197 is the tracking bug for the (rare) intermittent failures for this test. In bug 1780576, I am investigating why parent-controlled navigation increases the failure rate of this test to about 40% in automation.
Assignee | ||
Comment 2•2 years ago
|
||
It looks like this test is racy. If I add in await new Promise(r => setTimeout(r, 2000));
to the start of any of the content scripts, that test will fail.
Looking at test_ext_contentScripts_register.js, one test has run_at of "document_idle" instead of "document_end". Another couple of the scripts that do use "document_end" explicitly send a message when the content script has finished running. I'll try looking at the bug that added test_ext_userScripts_register.js to see if I can figure out what they are really trying to test here.
Updated•2 years ago
|
Assignee | ||
Comment 3•2 years ago
|
||
I thought about this some more, and I think my reasoning in the previous comment was bogus. So I'll have to come up with another theory.
Assignee | ||
Comment 4•2 years ago
|
||
I looked at the code that runs content scripts, and it does look like it is racey, even though my prior attempt to demonstrate that was probably bogus. I rewrote this test a bit to do a set timeout wait loop and that at least makes the test pass locally with Fission in verify mode. It does require an extra check fairly often. I'll have to see if this also fixes my parent-controlled navigation issue. While this is probably not the way to do it, at least it might suggest that my raciness theory is right.
Assignee | ||
Comment 5•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 6•2 years ago
|
||
My hacky patch fixes the intermittent failure, it looks like.
Updated•2 years ago
|
Comment 8•2 years ago
|
||
bugherder |
Description
•