As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 695108 - Android-only sporadic "REFTEST TEST-UNEXPECTED-FAIL | reftests/svg/filter-extref-differentOrigin-01.svg | image comparison (==)"
: Android-only sporadic "REFTEST TEST-UNEXPECTED-FAIL | reftests/svg/filter-ext...
: intermittent-failure
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: ARM Android
: -- normal (vote)
: mozilla10
Assigned To: Daniel Holbert [:dholbert]
: Jet Villegas (:jet)
Depends on: 686013
Blocks: 438871
  Show dependency treegraph
Reported: 2011-10-17 12:28 PDT by Daniel Holbert [:dholbert]
Modified: 2012-11-25 19:31 PST (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch: add <use> and flag as fails-on-android (2.46 KB, patch)
2011-10-17 14:56 PDT, Daniel Holbert [:dholbert]
bzbarsky: review+
Details | Diff | Splinter Review

Description User image Daniel Holbert [:dholbert] 2011-10-17 12:28:54 PDT
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:

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)
Comment 1 User image Daniel Holbert [:dholbert] 2011-10-17 12:31:50 PDT
I'll fix this up, as described at the end of Comment 0.
Comment 2 User image Boris Zbarsky [:bz] (still a bit busy) 2011-10-17 12:37:03 PDT
Or make the test always be an HTTP test and use an actual cross-origin load?
Comment 3 User image Daniel Holbert [:dholbert] 2011-10-17 13:36:03 PDT
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.
Comment 4 User image Daniel Holbert [:dholbert] 2011-10-17 14:56:10 PDT
Created attachment 567590 [details] [diff] [review]
patch: add <use> and flag as fails-on-android
Comment 5 User image Daniel Holbert [:dholbert] 2011-10-17 14:57:02 PDT
(running this through TryServer right now)
Comment 6 User image Daniel Holbert [:dholbert] 2011-10-17 18:57:48 PDT
This passed TryServer:

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 7 User image Boris Zbarsky [:bz] (still a bit busy) 2011-10-17 20:16:58 PDT
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?
Comment 8 User image Daniel Holbert [:dholbert] 2011-10-18 10:53:44 PDT
Filed bug 695385 on adding a mochitest, and updated the reftest.list comment to point to that bug instead of this one.

Comment 9 User image Marco Bonardo [::mak] 2011-10-19 03:12:53 PDT

I assume this can be mark fixed, if not please reopen.

Note You need to log in before you can comment on or make changes to this bug.