Closed Bug 695108 Opened 13 years ago Closed 13 years ago

Android-only sporadic "REFTEST TEST-UNEXPECTED-FAIL | reftests/svg/filter-extref-differentOrigin-01.svg | image comparison (==)"

Categories

(Core :: SVG, defect)

ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla10

People

(Reporter: dholbert, Assigned: dholbert)

References

Details

(Keywords: intermittent-failure, Whiteboard: [inbound])

Attachments

(1 file)

I added the test "filter-extref-differentOrigin-01.svg" last week, as part of Bug 686013. It checks that external SVG filters from a different origin will not load. Correct rendering (no filter) is green. Bad rendering (filter applied) is black. Today, it failed sporadically (twice in a row) on Android R2: https://tbpl.mozilla.org/php/getParsedLog.php?id=6892206&tree=Firefox https://tbpl.mozilla.org/php/getParsedLog.php?id=6893270&tree=Firefox This makes sense, because the reftest is served over file:// on Desktop (where url(../whatever) is different-origin, but over http on Android (where url(../whatever is same-origin). To fix this, we need to: - mark it as fails-if(Android) - add a <use> element that pulls in the external resource, so that it *is* accessible, we'll load it synchronously. (this will make it perma-"fail" on Android instead of sporadic-fail)
Blocks: 438871
OS: Linux → Android
Hardware: x86_64 → ARM
Summary: sporadic "REFTEST TEST-UNEXPECTED-FAIL | reftests/svg/filter-extref-differentOrigin-01.svg | image comparison (==)" → Android-only sporadic "REFTEST TEST-UNEXPECTED-FAIL | reftests/svg/filter-extref-differentOrigin-01.svg | image comparison (==)"
Whiteboard: [orange]
Depends on: 686013
I'll fix this up, as described at the end of Comment 0.
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
Or make the test always be an HTTP test and use an actual cross-origin load?
AFAIK, our reftest harness doesn't support cross-origin for HTTP tests. However, as bz points out on IRC, we could convert this into a mochitest and test actual cross-origin loads there, since the mochitest harness has multiple fake domains available for use. I think I'll fix this up per comment 0 to stop the randomorange, and then file a followup on adding an additional mochitest for "real" cross-origin loads.
(running this through TryServer right now)
This passed TryServer: https://tbpl.mozilla.org/?tree=Try&rev=949912e60891 I did 6 runs of Android R2, for good measure, and the 5 of those that are complete were all successful, modulo known-randomorange. (They failed this bug's tweaked reftest, as expected & asserted in the reftest manifest). Reftest-runs were green on Linux & Linux64, too.
Comment on attachment 567590 [details] [diff] [review] patch: add <use> and flag as fails-on-android r=me but maybe make the bug# comment point to the followup bug you file?
Attachment #567590 - Flags: review?(bzbarsky) → review+
Filed bug 695385 on adding a mochitest, and updated the reftest.list comment to point to that bug instead of this one. Landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/3fe4c90c9e1f
Whiteboard: [orange] → [orange][inbound]
Target Milestone: --- → mozilla10
https://hg.mozilla.org/mozilla-central/rev/3fe4c90c9e1f I assume this can be mark fixed, if not please reopen.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [orange][inbound] → [inbound]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: