Closed Bug 1257750 Opened 8 years ago Closed 8 years ago

Intermittent e10s browser_input_file_tooltips.js | Test timed out

Categories

(Toolkit :: UI Widgets, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
e10s + ---
firefox47 --- fixed
firefox48 --- fixed

People

(Reporter: philor, Assigned: Gijs)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Blocks: e10s-tests
tracking-e10s: --- → +
Blocks: 1251809
Jared, can you explain a bit why there's 2 mousemoves (to (100, 5) and to (100, 15) ) in the test, and what each of the 2 is supposed to do? The only orange after this commit is on 10.10, and the screenshot looks like this:

http://mozilla-releng-blobs.s3.amazonaws.com/blobs/mozilla-inbound/sha512/51f9cfa8eaf166f0353fdd0f326745464cf339da376d4d9d6376f1752ecb795cb0b4181bace399d530f7ba654f48412c1923c60c4b590500a430bf5804c8084e

which looks like maybe the mouse is ever so slightly too low to trigger the tooltip to show up? Or something?
Flags: needinfo?(jaws)
If I remember right, I saw somewhere in MXR that there was a threshold that a mouse needed to move to generate a mousemove event, and I was trying to trigger that. It doesn't have to necessarily move 10 pixels lower, we could adjust it to move 10 pixels in the horizontal axis and it should have the same effect.
Flags: needinfo?(jaws)
This is now top 5-6 orange.

We could potentially switch this test to be more unittest-y and just call the API directly like the other tooltiptextprovider tests are doing, after my e10s refactor. Jared, do you think that's a good idea, or would you prefer to keep the "actual" testing that the tooltip does show up? Meanwhile, I'll do a trypush to test the horizontal move thing from comment #7.
Flags: needinfo?(jaws)
Flags: needinfo?(jaws)
That's green with 20 runs ( https://treeherder.mozilla.org/#/jobs?repo=try&revision=e0bd83b967f2&group_state=expanded&exclusion_profile=false ), which compared to the current orange rate seems Pretty Okay.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Comment on attachment 8744369 [details]
MozReview Request: Bug 1257750 - fix intermittent failures in browser_input_file_tooltips.js, r?jaws

https://reviewboard.mozilla.org/r/48499/#review45203

Thanks for testing this approach. It would be AWESOME to keep this working through showing the tooltip the way that users would trigger it. Let's use the direct "unit-testy" approach if this attempt fails.
Attachment #8744369 - Flags: review?(jaws) → review+
There's still a trickle of these. Feels like that setTimeout is causing us grief here. Jared, is there anything else we could use / wait for?
Flags: needinfo?(jaws)
We could double the setTimeout value again? Will that take these down to 0? I don't have other ideas unfortunately, but doubling setTimeout is simple and if it gets us what we want then I think we should do it.
Flags: needinfo?(jaws) → needinfo?(gijskruitbosch+bugs)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #25)
> We could double the setTimeout value again? Will that take these down to 0?
> I don't have other ideas unfortunately, but doubling setTimeout is simple
> and if it gets us what we want then I think we should do it.

Done. We can check back in a few days (no use pushing to try, there's too little orange so we'd need too many retriggers to get any kind of confidence).
Flags: needinfo?(gijskruitbosch+bugs)
https://hg.mozilla.org/releases/mozilla-aurora/rev/78248731d23f9b774ce650c67e6f0ebcb73cdbdd
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Keywords: leave-open
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.