Intermittent devtools/client/shared/test/browser_html_tooltip_hover.js | Test timed out -

RESOLVED FIXED in Firefox 52

Status

defect
RESOLVED FIXED
3 years ago
Last year

People

(Reporter: intermittent-bug-filer, Assigned: jdescottes)

Tracking

({intermittent-failure})

unspecified
Firefox 54
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox52 fixed, firefox53 fixed, firefox54 fixed)

Details

(Whiteboard: [stockwell fixed])

Attachments

(1 attachment)

Component: Developer Tools → Developer Tools: Shared Components
this bug happens on opt/pgo builds most often where the runtime is typically <2 seconds.  As this is starting to show a pattern of 16 failures/day, this crosses our threshold of >30 failures/week to become a priority intermittent that we need to investigate and work on fixing.

here is data from a log on dec 28th [0]:
[task 2017-01-20T17:47:50.766944Z] 17:47:50     INFO - TEST-START | devtools/client/shared/test/browser_html_tooltip_hover.js
[task 2017-01-20T17:48:35.787040Z] 17:48:35     INFO - TEST-INFO | started process screentopng
[task 2017-01-20T17:48:36.289411Z] 17:48:36     INFO - TEST-INFO | screentopng: exit 0
[task 2017-01-20T17:48:36.290484Z] 17:48:36     INFO - Buffered messages logged at 17:47:50
[task 2017-01-20T17:48:36.290551Z] 17:48:36     INFO - Entering test bound 
[task 2017-01-20T17:48:36.291216Z] 17:48:36     INFO - Hover on each of the 4 boxes, expect the tooltip to appear
[task 2017-01-20T17:48:36.291273Z] 17:48:36     INFO - Show tooltip on box1
[task 2017-01-20T17:48:36.291316Z] 17:48:36     INFO - Buffered messages finished
[task 2017-01-20T17:48:36.292126Z] 17:48:36     INFO - TEST-UNEXPECTED-FAIL | devtools/client/shared/test/browser_html_tooltip_hover.js | Test timed out - 
[task 2017-01-20T17:48:36.292211Z] 17:48:36     INFO - MEMORY STAT | vsize 7310MB | residentFast 257MB | heapAllocated 95MB
[task 2017-01-20T17:48:36.292351Z] 17:48:36     INFO - TEST-OK | devtools/client/shared/test/browser_html_tooltip_hover.js | took 45045ms

For reference the screenshot is here:
https://public-artifacts.taskcluster.net/I6giYl-iSPOdx8Gtet9IDQ/0/public/test_info//mozilla-test-fail-screenshot_J_ewp6.png

looking at the code [1], we get the first message, but never get further, either we are stuck on tooltip.shown() or mousemove, or checkToolTipGeometry (I suspect the check based on the fact that we have the mouse in the center of the box via the screenshot)

:honza, can you take a look at this and see why this might be hanging primarily on linux32/64 opt/pgo?  

[0] https://public-artifacts.taskcluster.net/fk2_1-dWSE69KLIf1L-miQ/0/public/logs/live_backing.log
[1] https://dxr.mozilla.org/mozilla-central/source/devtools/client/shared/test/browser_html_tooltip_hover.js?q=path%3Abrowser_html_tooltip_hover.js&redirect_type=single#43
Flags: needinfo?(odvarko)
gentle ping, this is still a priority intermittent, can you take a look at this bug this week?
@Ricky: can you please take a look at this?
Honza
Flags: needinfo?(odvarko) → needinfo?(rchien)
Assignee: nobody → rchien
Status: NEW → ASSIGNED
Flags: needinfo?(rchien)
I suspect the timeout issue might be caused by yield tooltip.once("shown") event at 

http://searchfox.org/mozilla-central/source/devtools/client/shared/test/browser_html_tooltip_hover.js#45-47

However, I'm unable to reproduce the issue on my machine even though I ran 

./mach mochitest devtools/client/shared/test/browser_html_tooltip_hover.js --repeat 15

many times.
According logs timeout failures appear after `INFO - Show tooltip on box1` for example in https://public-artifacts.taskcluster.net/M5xN9_xjQl6dgeXMVQSL6g/0/public/logs/live_backing.log

INFO - Show tooltip on box1
INFO - TEST-UNEXPECTED-FAIL | devtools/client/shared/test/browser_html_tooltip_hover.js | Test timed out - 

So, it apparently point out the timeout which is due to yield tooltip.once("shown") event. Trace into implementation of HTMLTooltip component, this.emit("shown"); call looks robust. As a result, the root cause might be at EventUtils.synthesizeMouseAtCenter(box, { type: "mousemove" }, doc.defaultView); itself.
Julian, do you have any clue with that?
Flags: needinfo?(jdescottes)
I can reproduce the issue on a slow Ubuntu VM 
(btw we have https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Using_the_VM which is super helpful to repro this kind of intermittents).

Adding any kind of delay after call createHost fixes the issue. When you look at what createHost is doing, it actually waits for the DOMContentLoaded event before resolving. In my opinion DOMContentLoaded is not the proper event to wait for here. We are loading stylesheets in this test and we are starting to simulate events right after the beginning of the test. I think for this reason, we should wait for "load" before starting the test. 

Locally this fixes the issue. 
Here is a try push with the changeset: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c97a1354b3685be655780ea769e789aff3029e16

Ricky: Do you mind if I take this bug? I missed the fact you assigned it to yourself, sorry :(
Flags: needinfo?(jdescottes) → needinfo?(rchien)
Ah, VM is a good approach for finding timeout issue. 

Thanks for helping this \o/. I'm going to assign this bug to you.
Assignee: rchien → jdescottes
Flags: needinfo?(rchien)
Thanks Ricky! Started a few retriggers of the test on Linux 64 opt. Submitting for review.
Comment on attachment 8833310 [details]
Bug 1313271 - wait for load in browser_html_tooltip_hover;

https://reviewboard.mozilla.org/r/109574/#review110604

Looks great! I like the waitUntil solution. Let's wait for try green. Thanks
Attachment #8833310 - Flags: review?(rchien) → review+
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c2d20fb73fc9
wait for load in browser_html_tooltip_hover;r=rickychien
https://hg.mozilla.org/mozilla-central/rev/c2d20fb73fc9
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 54
Whiteboard: [stockwell fixed]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.