Closed Bug 1369197 Opened 8 years ago Closed 3 years ago

Intermittent browser/components/extensions/test/browser/browser_ext_browserAction_contextMenu.js | Test timed out | Extension left running at test shutdown

Categories

(WebExtensions :: General, defect, P5)

Product:
WebExtensions
Component:
General
Platform:
Unspecified
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1775556

People

(Reporter: intermittent-bug-filer, Unassigned)

References

(Regression)

Details

(Keywords: intermittent-failure, regression, Whiteboard: [stockwell disabled])

Attachments

(1 file)

Bug 1369197 - Wait for customizationready when exiting customize mode in browserAction contentMenu tests. r?robwu!
47 bytes, text/x-phabricator-request
Details | Review
Tomislav - Your fix for bug 1351638 was quite effective. Unfortunately, this similarly-named test continues to fail. Might it have a similar problem? Do you have time to have a look?
Flags: needinfo?(tomica)
Whiteboard: [stockwell needswork]
Despite being similarly-named to bug bug 1351638, this is testing a completely unrelated thing. I investigated a bit, but nothing obvious jumps out at me. Unfortunately I don't have the time to dive deeper in the next week or two. Though, from my reading of the logs, this is failing in the preparation step, not in the actual thing being tested here. And considering that failures are localized to linux builds, disabling this test there wouldn't be the worst thing IMO if nobody else has the time to investigate further.
Flags: needinfo?(tomica)
:andym - Can you find someone to investigate this frequent intermittent failure? If you'd prefer to skip the test, just let me know.
Flags: needinfo?(amckay)
Pushed by gbrown@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/0a5cf86cabb3 Disable test browser_ext_browserAction_contextMenu.js for frequent intermittent failures; r=me,test-only
Keywords: leave-open
Whiteboard: [stockwell needswork] → [stockwell disabled]
Priority: -- → P5
Flags: needinfo?(amckay) → needinfo?(bob.silverberg)
This is disabled only on Linux, so a lower priority. Leaving at P5 for now.
Component: WebExtensions: Untriaged → WebExtensions: General
Flags: needinfo?(bob.silverberg)
Product: Toolkit → WebExtensions

Hi Andrew, spikes here seem to be from Bug 1563062, can you please take a look?

Flags: needinfo?(aswan)
Regressed by: 1563062

If there's a connection between these failures and bug 1563062, it must be something indirect. E.g., removal of other test cases changed timing or initial conditions or something, making the underlying problem more likely to occur.
I'm not very familiar with this test, looks like Rob was the last person to make non-trivial changes to it, perhaps he has ideas.

Flags: needinfo?(aswan) → needinfo?(rob)

From the log from comment 36:

14:04:59 INFO - TEST-PASS | browser/components/extensions/test/browser/browser_ext_browserAction_contextMenu.js | Abuse report frame has the expected reportEntryPoint -
14:04:59 INFO - Closing the about:addons tab
14:04:59 INFO - Pin the browserAction and another button to the overflow menu
14:04:59 INFO - Wait until the overflow menu is ready
14:04:59 INFO - Waiting for overflow button to have non-0 size
14:04:59 INFO - Test overflow menu context menu in browserAction
14:04:59 INFO - Open browserAction context menu in customizationPanelItemContextMenu
14:04:59 INFO - Buffered messages finished
14:04:59 INFO - TEST-UNEXPECTED-FAIL | browser/components/extensions/test/browser/browser_ext_browserAction_contextMenu.js | Test timed out -

Test appears to be stuck at

This subtest was newly added in bug 1544928, but the runTestContextMenu logic was largely pre-existing and unchanged.
There is a potentially significant difference:

I cannot reproduce the issue locally on macOS even with --verify, but adding an explicit wait for the customizationready event does not cause the test to fail (even with --verify).

Luca, why was this omitted? Would waiting for the customizationready event reduce the number of failures?

Flags: needinfo?(rob) → needinfo?(lgreco)
Summary: Intermittent browser/components/extensions/test/browser/test-oop-extensions/browser_ext_browserAction_contextMenu.js | Test timed out | Extension left running at test shutdown → Intermittent browser/components/extensions/test/browser/browser_ext_browserAction_contextMenu.js | Test timed out | Extension left running at test shutdown

(In reply to Rob Wu [:robwu] from comment #40)

I cannot reproduce the issue locally on macOS even with --verify, but adding an explicit wait for the customizationready event does not cause the test to fail (even with --verify).

Luca, why was this omitted? Would waiting for the customizationready event reduce the number of failures?

I was also able to reproduce it locally on linux using --verify.

I don't see any reason why we should have omitted that part in the test that is timing out (we may have just missed to notice that differences),
and so I'm going to attach to this issue a patch with that change.

Looking at a some of failures tracked by orangefactor, and the screenshots captured during the failures, it seems that when the test gets stuck the context menu for the tab is actually being triggered instead of the context menu of the browserAction button (which I think it may be happening when the customize mode is still not completely ready on the tab, and we may not be synthesizing the mouse events on the screen position we expect).

I gave it a try locally and in a try push here:

there is still a failure in TV (on osx debug), but it isn't the timeout failure that is currently spiking.

Flags: needinfo?(lgreco)
Pushed by luca.greco@alcacoop.it: https://hg.mozilla.org/integration/autoland/rev/28d7d0fe74e2 Wait for customizationready when exiting customize mode in browserAction contentMenu tests. r=robwu

The latest failure was on the 16th of July, which was the day that the above patch landed.

Assignee: nobody → lgreco
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED

Re-opening though, because the test is still disabled on Linux.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Recent occurences are fixed by the backout mentioned above.
Removing the ni here and leaving it on the regressed by bug.

Flags: needinfo?(dao+bmo)
Assignee: lgreco → nobody
Severity: normal → S3
OS: Unspecified → Linux
Has Regression Range: --- → yes
Status: REOPENED → RESOLVED
Closed: 6 years ago → 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: