Closed Bug 624097 Opened 9 years ago Closed 8 years ago

Intermittent timeout in browser_bug591465.js | Test timed out


(Toolkit :: Add-ons Manager, defect)

Not set





(Reporter: mossop, Unassigned)



(Keywords: intermittent-failure)


(2 files)

Attached image screenshot
TEST-START | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser-window/browser_bug591465.js
TEST-PASS | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser-window/browser_bug591465.js | Should have an add-ons manager window
TEST-PASS | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser-window/browser_bug591465.js | Should be displaying the correct UI
TEST-INFO | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser-window/browser_bug591465.js | Waiting for initialization
TEST-INFO | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser-window/browser_bug591465.js | Running test 1
TEST-PASS | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser-window/browser_bug591465.js | Should have found addon element
TEST-INFO | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser-window/browser_bug591465.js | Opening context menu on enabled extension item
TEST-INFO | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser-window/browser_bug591465.js | Longer timeout required, waiting longer...  Remaining timeouts: 1
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser-window/browser_bug591465.js | Test timed out

Very weird screenshot
Running this test by itself over and over again, I've been able to reproduce this locally - with it stopping at various different points during the test. For whatever reason, the context menu isn't always opening - using the mouse to open the context menu manually will let the test continue and complete successfully. I tried putting the sythesizeMouse() calls on a delay, which didn't help. I don't think its related to any of the changesets mentioned in comment 1 - since I've seen it happen at different parts of the test (ie, both list view and detail view).
Attached patch WiP v1Splinter Review
I was having this test timeout quite frequently on my linux laptop - this patch makes it always pass. Making it wait for popuphidden events helps significantly, but I still had the odd test timeout. Adding a setTimeout to delay the synthesized mouse click fixed the remaining timeouts... but that's using setTimeout() - using executeSoon() wasn't enough. Not sure where to go from here.
Attachment #506636 - Flags: feedback?(dtownsend)
Comment on attachment 506636 [details] [diff] [review]
WiP v1

Much as I hate timeouts in tests I'll take them if they actually reduce the level of orange. It does however suggest that we are missing something here, maybe Enn knows why the timeout is necessary and could suggest an alternative?
Attachment #506636 - Flags: feedback?(enndeakin)
Attachment #506636 - Flags: feedback?(dtownsend)
Attachment #506636 - Flags: feedback+
Don't know. It hangs waiting for a context menu to open? Does the context menu open eventually?

It is the same old windows aren't active on Linux problem as many other tests?
(In reply to comment #89)

I can reproduce this issue too.

> Don't know. It hangs waiting for a context menu to open?


> Does the context menu open eventually?


Mouse event is absorbed exactly at this check.
Hmm, there is another possibility of absorbing mouse event. I can not catch it yet.
(In reply to comment #101)
> Mouse event is absorbed exactly at this check. 

Then it is the same problem as other tests on Linux that need the window active.
Attachment #506636 - Flags: feedback?(enndeakin)
Those last three are pretty clearly unrelated to this failure
No apparent timeouts in the past 11 months, gonna call this one magically fixed.
Closed: 8 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.