Closed Bug 1543639 Opened 5 years ago Closed 5 years ago

Intermittent text-svgglyphs/svg-glyph-extents.html == text-svgglyphs/svg-glyph-extents-ref.html | load failed: timed out waiting for reftest-wait to be removed

Categories

(Core :: SVG, defect, P5)

Product:
Core
Component:
SVG
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla71
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- fixed
firefox69 --- wontfix
firefox70 --- fixed
firefox71 --- fixed

People

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

References

Details

(Keywords: intermittent-failure, regression)

Attachments

(1 file)

Bug 1543639 - Fix svg-glyph-extents reftest timeouts when running on Fennec with webcompat extension installed. r?heycam!
47 bytes, text/x-phabricator-request
Details | Review

This is a regression of Bug 1564594:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr68&searchStr=reftest-1proc-53%2Cr-1proc%28r53%29&group_state=expanded&selectedJob=264550616

:twisniewski could you please take a look? it's really high frequency on ESR68

Flags: needinfo?(twisniewski)

:nataliaCs, would you know if is there a way I can run this test from mach try fuzzy? I tried the closest task I could find in the following run, but it seems to be passing for me: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3cd9c57935ff3118c0f1d533510aa3ac8c6fc91e

Flags: needinfo?(twisniewski) → needinfo?(ncsoregi)

Hi Thomas, your try push ran a tier2 job and in this case the failure is tier1, specifically android 4.3 api16+ debug reftests without e10s test-android-em-4.3-arm7-api-16/debug-reftest-1proc-53 r-1proc(r53)

To run this job in the mach try fuzzy I think you need to select test-android-em-4.3-arm7-api-16/debug-fennec-reftest-1proc-53

Flags: needinfo?(ncsoregi) → needinfo?(twisniewski)

Thanks, that was the test to try. Based on my own try-runs, I just don't know why this is happening. It doesn't seem like the results are consistent with any single part of my patch:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=686caa7aece46ee2cc244beecdca3cb20b9cc749
https://treeherder.mozilla.org/#/jobs?repo=try&revision=dba9c1b4f3f265909b1e5e90553f325508c554ab
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5b3e782871c0ea3f726b5b8cfee700d0f6994a01
https://treeherder.mozilla.org/#/jobs?repo=try&revision=9cd7e82f3ef855e20e340f38894dfd885d6c4643

But running the test-case manually on a live browser doesn't cause any failures (it ends up removing the reftest-wait CSS class), so after looking at the regressions caused by my patch I honestly think that our test framework just isn't playing well with system addons on Fennec (perhaps ones adding webRequest listeners, though the results try-runs show pretty inconsistent results on this test, compared to bug 1553971).

I'll ask around and see if I can get any further clues.

I investigated this failure a bit (given that I had everything in place while investigating Bug 1553971 and it seemed worth to double-check if this failure was unveiling a different issue I took the opportunity to look into it).

This one (unlike Bug 1553971) looked like a race, because the HTTP requests intercepted by the webcompat extension (one related to the test html page and the other one related to the font loaded by the test html page) are both suspended and then resumed as expected (and none of the requests intercepted seem to be getting stuck waiting for the webRequest listeners to resolve as in Bug 1553971).

When the webcompat extension is installed, the font request is still loaded successfully as expected but with an additional lag time ([1]), and so when the test setup function is executed ([2]) and registers the "animationend" listener it may be already too late (because the animation may have been already completed and the "animationend" event will never be fired again).

This race seems something that can be easily fixed with a small tweak to the test case, I'm going to attach a proposed patch to this issue.

[1]: the lag time is due to the fact that the request has to be suspended, a webRequest event has to be fired to run the webRequest listener, then we wait for the promised result related to the listener execution to be resolved and after that we resume the font request)
[2]: which happens when the document load is completed, which include loading the font

Flags: needinfo?(twisniewski)

With the attached patch applied, the test is consistently passing in my local environment (an android 4.3. arm emulator).

The patch avoids the race described in comment 25 by making sure that the animation is only going to start once the font has been loaded and the "animationend" event listener subscribed.

Pushed by luca.greco@alcacoop.it:
https://hg.mozilla.org/integration/autoland/rev/2dcb78435500
Fix svg-glyph-extents reftest timeouts when running on Fennec with webcompat extension installed. r=heycam

https://hg.mozilla.org/mozilla-central/rev/2dcb78435500

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox71: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Assignee: nobody → lgreco
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: