Intermittent [TV-fis] /browser_toolbarbutton_menu_show_in_folder.js | Uncaught exception received from previously timed out test - ViewShown listener on #appMenu-protonMainView not removed before the end of test | uncaught exception - Error: No DOM node
Categories
(Firefox :: Bookmarks & History, defect, P5)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox98 | --- | unaffected |
firefox99 | --- | unaffected |
firefox100 | --- | affected |
People
(Reporter: intermittent-bug-filer, Unassigned)
References
(Regression)
Details
(Keywords: intermittent-failure, regression)
Attachments
(1 obsolete file)
Filed by: nbeleuzu [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer?job_id=371137857&repo=autoland
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/PZcKJWqGTo28n9LMd7VE8w/runs/0/artifacts/public/logs/live_backing.log
Reftest URL: https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/PZcKJWqGTo28n9LMd7VE8w/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1
[task 2022-03-15T17:56:24.444Z] 17:56:24 INFO - TEST-START | browser/components/places/tests/browser/browser_toolbarbutton_menu_show_in_folder.js
[task 2022-03-15T17:57:09.460Z] 17:57:09 INFO - TEST-INFO | started process screentopng
[task 2022-03-15T17:57:09.700Z] 17:57:09 INFO - TEST-INFO | screentopng: exit 0
[task 2022-03-15T17:57:09.700Z] 17:57:09 INFO - Buffered messages logged at 17:56:24
[task 2022-03-15T17:57:09.701Z] 17:57:09 INFO - Entering test bound toolbarBookmarkShowInFolder
[task 2022-03-15T17:57:09.701Z] 17:57:09 INFO - TEST-PASS | browser/components/places/tests/browser/browser_toolbarbutton_menu_show_in_folder.js | The panel is closed to begin with. - "closed" == "closed" -
[task 2022-03-15T17:57:09.702Z] 17:57:09 INFO - Buffered messages finished
[task 2022-03-15T17:57:09.702Z] 17:57:09 INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/browser/browser_toolbarbutton_menu_show_in_folder.js | Test timed out -
[task 2022-03-15T17:57:09.703Z] 17:57:09 INFO - Not taking screenshot here: see the one that was previously logged
[task 2022-03-15T17:57:09.705Z] 17:57:09 INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/browser/browser_toolbarbutton_menu_show_in_folder.js | Uncaught exception received from previously timed out test - ViewShown listener on #appMenu-protonMainView not removed before the end of test
[task 2022-03-15T17:57:09.706Z] 17:57:09 INFO - GECKO(1929) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2022-03-15T17:57:09.706Z] 17:57:09 INFO - GECKO(1929) | MEMORY STAT | vsize 3156MB | residentFast 438MB | heapAllocated 196MB
[task 2022-03-15T17:57:09.708Z] 17:57:09 INFO - TEST-OK | browser/components/places/tests/browser/browser_toolbarbutton_menu_show_in_folder.js | took 45014ms
Updated•2 years ago
|
Comment 1•2 years ago
|
||
:lebar, since you are the author of the regressor, bug 1741603, could you take a look?
For more information, please visit auto_nag documentation.
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1741603
Updated•2 years ago
|
I haven’t been able to reproduce this locally. Mind you, it’s likely a timing issue that presents itself intermittently with having the click()
come before the waitForEvent
as seen in the code snippet below. :standard8, I was wondering if you, perhaps, have a suggestion, so that I don't submit a change that ends up just being a shot in the dark. Also, is there a way that I can test locally that more closely approximates the testing environment?
appMenuBookmarks.click();
let bookmarksView = document.getElementById("PanelUI-bookmarks");
let bmViewPromise = BrowserTestUtils.waitForEvent(bookmarksView, "ViewShown");
await bmViewPromise;
Comment 4•2 years ago
|
||
(In reply to Lebar from comment #3)
I haven’t been able to reproduce this locally. Mind you, it’s likely a timing issue that presents itself intermittently with having the
click()
come before thewaitForEvent
as seen in the code snippet below. :standard8, I was wondering if you, perhaps, have a suggestion, so that I don't submit a change that ends up just being a shot in the dark.
I'm not sure its the waitForEvent
there, as we seem to do that in other tests as well, so I'm a little puzzled. It also might depend on exactly which bit of the test its failing - I see there's about 3 promises there before we'd have more test output, so it might be failing somewhere slightly later.
Also, is there a way that I can test locally that more closely approximates the testing environment?
It looks like it is failing only on Windows & Linux, so if you are on one of those you can do:
./mach mochitest --verify browser/components/places/tests/browser/browser_toolbarbutton_menu_show_in_folder.js
That runs it multiple times in slightly different ways.
If you can't reproduce like this, I'm quite happy push some test patches to our try server to see if we can get out more detail.
Thanks for the suggestion. I ran mochitest --verify on Linux and it consistently ran successfully:
Ran 180 checks (150 subtests, 30 tests)
Expected results: 180
Unexpected results: 0
So perhaps I can take you up on the try server. What is the best way to submit patches for the try server?
Comment hidden (Intermittent Failures Robot) |
Updated•2 years ago
|
Comment 7•2 years ago
|
||
(In reply to Lebar from comment #5)
So perhaps I can take you up on the try server. What is the best way to submit patches for the try server?
Using a WIP phabricator patch should be fine - just attach it to the bug, and don't put a reviewer in the commit message. It'll automatically mark it as WIP.
Comment 9•2 years ago
|
||
https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Description
•