Intermittent toolkit/mozapps/extensions/test/xpinstall/browser_doorhanger_installs.js | single tracking bug
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox106 | --- | fixed |
People
(Reporter: jmaher, Assigned: rpl)
References
Details
(Keywords: intermittent-failure, intermittent-testcase, Whiteboard: [stockwell unknown])
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Reporter | ||
Comment 1•2 years ago
|
||
Additional information about this bug failures and frequency patterns can be found by running: ./mach test-info failure-report --bug 1775898
Comment hidden (Intermittent Failures Robot) |
Updated•2 years ago
|
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 12•2 years ago
|
||
There have been 44 failures in the last 7 days: https://treeherder.mozilla.org/intermittent-failures/bugdetails?startday=2022-08-19&endday=2022-08-26&tree=trunk&bug=1775898
Happens on:
- linux1804-64-qr opt and debug
- linux1804-64-shippable-qr opt
- windows10-32-2004-qr debug and opt
Recent failure log: https://treeherder.mozilla.org/logviewer?job_id=388505692&repo=autoland&lineNumber=13246
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 14•2 years ago
|
||
I'm looking into this, looking to the failures tracked on orangefactor the intermittent failures have been visibly raising in frequency around 10 days ago and so it seems likely that this may be related to the changes landed from Bug 1784292.
Assignee | ||
Comment 15•2 years ago
|
||
The failures triggered after the changes introduced in this test from Bug 1784292 and tracked by orangefactor
are all triggered from the test case named test_blockedInstallDomain_with_unified_extensions
:
-
in that test case we are using a new chrome window (because the test case covers the behaviors expected when
the unified extension button have been enabled by flipping the related pref) and the new chrome
window is closed shortly after calling BrowserTestUtils.openNewForegroundTab. -
By opening and quickly closing a new chrome window, of all the tests in that test file,
test_blockedInstallDomain_with_unified_extensions
is the only one that have a pretty
good chance to trigger this kind of failure. -
the failure is triggered when the chrome window has been already closed by the time all the promises that
BrowserTestUtils.openNewForegroundTab is internally waiting on (see the lines linked below) are settled,
and that triggers the failure due to an uncaught rejection triggered as a side-effect of trying to access
tabbrowser.ownerGlobal.windowGlobalChild for a chrome window that is already gone:
The attached patch just adds an await on the call to BrowserTestUtils.openNewForegroundTab, which prevents
the intermittent failure from being triggered.
As a side note (either as an alternative approach to the one currently in this patch or indipendently from
fixing this specific intermittent):
it seems worth confirming if we could be changing BrowserTestUtils.openNewForegroundTab to expect
the possibility that the chrome window have been closed and just omit the innerWindowId in the
profile marker if collected too late to be able to retrieve the innerWindowId.
Comment 16•2 years ago
|
||
Comment 17•2 years ago
|
||
bugherder |
Comment hidden (Intermittent Failures Robot) |
Updated•2 years ago
|
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Description
•