Closed Bug 1759751 Opened 2 years ago Closed 2 years ago

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)

defect

Tracking

()

RESOLVED INCOMPLETE
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
Summary: Intermittent [TV-fis] 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 → 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
Regressed by: 1741603

:lebar, since you are the author of the regressor, bug 1741603, could you take a look?
For more information, please visit auto_nag documentation.

Flags: needinfo?(lebar)

Set release status flags based on info from the regressing bug 1741603

Has Regression Range: --- → yes

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;
Flags: needinfo?(lebar) → needinfo?(standard8)

(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 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.

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.

Flags: needinfo?(standard8)

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?

Flags: needinfo?(standard8)

(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.

Flags: needinfo?(standard8)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
Attachment #9269498 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: