739711 - layout/reftests/svg/as-image have 7 SVG-as-an-image + canvas tests that fail on android when we turn browser.tabs.remote=false

Status: RESOLVED DUPLICATE of bug 739708

(Core :: Graphics: Canvas2D, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

On android xul, we run with e10s and our reftest harness will setup the xul window to have the remote=true attribute.  For native fennec we have the preference to turn on e10s set, but we don't read it.  This means that reftest is still thinking we are remote, but in reality we are not.  

In trying to turn this off, I found that we have 7 tests which pass on android-xul, but are failing now on native with the browser.tabs.remote pref turned off.

The log file showing this is here:
http://people.mozilla.org/~jmaher/android_reftests/as-image.log

Comment 1

[Daniel Holbert [:dholbert]]

The tests are:
 canvas-drawImage-simple-1a.html
 canvas-drawImage-simple-1b.html
 canvas-drawImage-scale-1a.html
 canvas-drawImage-scale-1b.html
 canvas-drawImage-scale-1c.html
 canvas-drawImage-slice-1a.html
 canvas-drawImage-origin-clean-1.html

They all rely on drawing an SVG image into an HTML5 canvas.

In each case, the testcase is blank (indicating that the draw didn't complete in time, or something).

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

do we not support canvas on native fennec?  Maybe there is something simple we can do to fix this?

Comment 3

[Daniel Holbert [:dholbert]]

I assume we support it, but maybe not (?) -- did other canvas testcases (outside of /svg/) fail in these reftest runs?

Comment 4

[Joel Maher ( :jmaher ) (UTC -8)]

it appears that we have other canvas tests failing in bug 739708.  Could be a theme

Comment 5

[Daniel Holbert [:dholbert]]

OK, I'm going to assume the issue here is with canvas, then --> reclassifying this bug.

If the tests here still have issues after bug 739708 is addressed, then this should potentially move back to Core|SVG.

Comment 6

[Geoff Brown [:gbrown]]

I confirmed Joel's observations on Friday and noted that the test images appear to be displayed correctly (they are certainly not blank) when loaded stand-alone or during a test run. The issue seems to be related to the screenshot...timing? retrieving the bitmap from the canvas??

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I suspect timing. dholbert, try adding some logging that fires when an SVG image is drawn? Then we can see if we're trying to draw the image or not, and when.

Comment 8

[Daniel Holbert [:dholbert]]

I can try that, sure. (though note that this seems to be an issue with canvas in general, not just SVG images, per comments 4-5)

jmaher, have we already verified that other complex reftests with "reftest-wait" are passing?  (this isn't just a case of us the harness ignoring "reftest-wait" in this configuration?)

Comment 9

[Daniel Holbert [:dholbert]]

The 7 failing reftests (listed in comment 1) seem to be a random sampling of the (larger) set of 10 reftests in this directory, with no clear difference between the ones that failed vs. passed.  (e.g. canvas-drawImage-slice-1a.html and canvas-drawImage-slice-1b.html are nearly identical, but the the former one failed while the latter one passed)

So, I going to assume that all 10 of the svg/as-image/canvas-drawImage-* tests have a chance of failing, and the 7 highlighted here were just the ones that failed in one particular run.  (jmaher, correct me if I'm wrong -- not sure if you've run these tests multiple times under this configuration)

Comment 10

[Geoff Brown [:gbrown]]

When I ran a test of all of the tests in this directory, exactly 7 failed -- the same 7 that jmaher reported.

Comment 11

[Daniel Holbert [:dholbert]]

Sorry -- I just noticed that the other 3 as-image/canvas tests are all flagged as "fails" or "fails-if(!azureQuartz)"  So they're all failing in this configuration, but only the 7 failures from comment 1 are _unexpected_ failures.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: add some diagnostic printfs

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7)
> I suspect timing. dholbert, try adding some logging that fires when an SVG
> image is drawn? Then we can see if we're trying to draw the image or not,
> and when.

The "and when" part is tricky/impossible to judge, since any logging from Gecko itself ends up in logcat, which is separate from the actual reftest output for Android. (and which has to be manually captured -- it doesn't end up in test-runners' logs)  So we can't really compare drawing-logging to "REFTEST UNEXPECTED FAIL" to see which came first, sadly.

Still, it's probably worthwhile to verify that we're getting to the drawImage call at all.

So, this patch adds debugging printfs at the beginning & end of VectorImage::Draw and VectorImage::GetFrame (which is specific to things like canvas and feImage, IIRC -- it isn't used for drawing normal <img>).

Also, note that technically this code won't be called when our SVG image draws to the screen -- this is used by nsLayoutUtils::SurfaceFromElement to generate a surface, which then gets drawn to the canvas separately (synchronously I think (?)).

Comment 13

[Daniel Holbert [:dholbert]]

Landed diagnostic patch:
  https://hg.mozilla.org/integration/mozilla-inbound/rev/ca2cbec4255a

Comment 14

[Joel Maher ( :jmaher ) (UTC -8)]

I don't see these messages in adb logcat (for a single failing test), this is what I do see:
I/Gecko   (32502): REFTEST INFO | Dumping JSON representation of sandbox 
I/Gecko   (32502): REFTEST INFO | {"isDebugBuild":false,"xulRuntime":{"widgetToolkit":"android","OS":"Android","__exposedProps__":{"widgetToolkit":"r","OS":"r","XPCOMABI":"r","shell":"r"},"XPCOMABI":"arm-eabi-gcc3"},"d2d":false,"azureQuartz":false,"layersGPUAccelerated":false,"layersOpenGL":false,"Android":true,"cocoaWidget":false,"gtk2Widget":false,"qtWidget":false,"winWidget":false,"http":{"__exposedProps__":{"userAgent":"r","appName":"r","appVersion":"r","vendor":"r","vendorSub":"r","product":"r","productSub":"r","platform":"r","oscpu":"r","language":"r","misc":"r"},"userAgent":"Mozilla/5.0 (Android; Mobile; rv:14.0) Gecko/14.0 Firefox/14.0a1","appName":"Mozilla","appVersion":"5.0","product":"Gecko","productSub":"14.0","platform":"Android","oscpu":"Linux armv7l","misc":"rv:14.0"},"haveTestPlugin":false,"windowsDefaultTheme":false,"nativeThemePref":false,"prefs":{"__exposedProps__":{"getBoolPref":"r","getIntPref":"r"},"_prefs":{"root":"","PREF_INVALID":0,"PREF_STRING":32,"PREF_INT":64,"PREF_BOOL":128}},"browserIsRemote":fals
I/Gecko   (32502): Compositor: Composite took 34 ms.
E/GeckoConsole(32502): [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must to be declared in the document or in the transfer protocol." {file: "http://192.168.1.109:8888/tests/layout/reftests/svg/as-image/canvas-drawImage-origin-clean-1.html" line: 0}]
I/Gecko   (32502): Compositor: Composite took 34 ms.
I/Gecko   (32502): Compositor: Layers update took 35 ms (blocking gecko).
E/GeckoConsole(32502): [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must to be declared in the document or in the transfer protocol." {file: "http://192.168.1.109:8888/tests/layout/reftests/svg/as-image/lime100x100-ref.html" line: 0}]
I/Gecko   (32502): Compositor: Composite took 58 ms.
I/Gecko   (32502): Compositor: Composite took 39 ms.
I/wpa_supplicant( 1345): CTRL-EVENT-STATE-CHANGE id=-1 state=2
V/WifiMonitor( 1021): Event [CTRL-EVENT-STATE-CHANGE id=-1 state=2]
V/WifiStateTracker( 1021): Changing supplicant state: INACTIVE ==> SCANNING
D/NetworkStateTracker( 1021): setDetailed state, old =IDLE and new state=SCANNING
D/ConnectivityService( 1021): Dropping ConnectivityChange for WIFI: DISCONNECTED/SCANNING
E/GeckoConsole(32502): [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must to be declared in the document or in the transfer protocol." {file: "data:text/html,%3C%21%2D%2DCLEAR%2D%2D%3E" line: 0}]
E/GeckoConsole(32502): [JavaScript Warning: "Duplicate resource declaration for 'gre-resources' ignored." {file: "jar:jar:file:///data/app/org.mozilla.fennec-1.apk!/omni.ja!/chrome/nonlocalized.manifest" line: 6}]
E/GeckoConsole(32502): Could not read chrome manifest 'file:///data/data/org.mozilla.fennec/chrome.manifest'.
E/GeckoConsole(32502): [JavaScript Warning: "Bootstrapped manifest not allowed to use 'component' directive." {file: "file:///mnt/sdcard/tests/reftest/profile/extensions/[e-mail]/chrome.manifest" line: 1}]
E/GeckoConsole(32502): [JavaScript Warning: "Bootstrapped manifest not allowed to use 'interfaces' directive." {file: "file:///mnt/sdcard/tests/reftest/profile/extensions/[e-mail]/chrome.manifest" line: 3}]
E/GeckoConsole(32502): [JavaScript Warning: "Bootstrapped manifest not allowed to use 'contract' directive." {file: "file:///mnt/sdcard/tests/reftest/profile/extensions/[e-mail]/chrome.manifest" line: 4}]
D/dalvikvm(32502): threadid=12: thread exiting, not yet detached (count=0)
I/wpa_supplicant( 1345): CTRL-EVENT-SCAN-RESULTS  Ready
D/dalvikvm( 1492): GC_EXPLICIT freed 517 objects / 101680 bytes in 57ms
D/dalvikvm( 1492): GC_EXPLICIT freed 241 objects / 17456 bytes in 32ms
D/dalvikvm( 1492): GC_EXPLICIT freed 251 objects / 18056 bytes in 20ms
E/libEGL  (32502): call to OpenGL ES API with no current context (logged once per thread)
I/GeckoAppShell(32502): XRE exited
I/GeckoAppShell(32502): we're done, good bye

Comment 15

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/ca2cbec4255a

Comment 16

[Daniel Holbert [:dholbert]]

Just chatted with jmaher -- his output in Comment 14 was from an opt build, and the diagnostics are #ifdef DEBUG, so that's presumably why they didn't print.

He's trying w/ a debug build at some point soon I think. (thanks in advance!)

Comment 17

[Daniel Holbert [:dholbert]]

OK, here's output that jmaher captured during a reftest run, with the diagnostic output (which confirms we _are_ indeed drawing the SVG image via GetFrame/Draw, to generate a surface which gets passed off to the canvas):

E/GeckoConsole( 5070): [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must to be declared in the document or in the transfer protocol." {file: "http://192.168.1.109:8888/tests/layout/reftests/svg/as-image/canvas-drawImage-origin-clean-1.html" line: 0}]
I/Gecko   ( 5070): ###!!! ASSERTION: QueryInterface needed: 'query_result.get() == mRawPtr', file ../../../dist/include/nsCOMPtr.h, line 532
I/Gecko   ( 5070): Compositor: Composite took 35 ms.
I/Gecko   ( 5070): Beginning VectorImage::GetFrame (bug 739711 diagnostic)
I/Gecko   ( 5070): Beginning VectorImage::Draw (bug 739711 diagnostic)
I/Gecko   ( 5070): Completing VectorImage::Draw (bug 739711 diagnostic)
I/Gecko   ( 5070): Completing VectorImage::GetFrame (bug 739711 diagnostic)
I/Gecko   ( 5070): Compositor: Composite took 31 ms.
I/Gecko   ( 5070): nsWindow::SetFocus: can't set focus without raising, ignoring aRaise = false!
I/Gecko   ( 5070): AndroidBridge::NotifyIMEEnabled
I/Gecko   ( 5070): Compositor: Composite took 41 ms.
I/Gecko   ( 5070): Compositor: Composite took 30 ms.
I/Gecko   ( 5070): Compositor: Layers update took 31 ms (blocking gecko).
I/Gecko   ( 5070): Compositor: Composite took 40 ms.
I/Gecko   ( 5070): AndroidBridge::GetDPI
I/Gecko   ( 5070): Compositor: Composite took 39 ms.

I'm duping this to bug 739708, since it's almost certainly the same problem in both bugs, and that bug is more general (about canvas not working, rather than being about svg-drawn-to-canvas not working)

Comment 18

[Daniel Holbert [:dholbert]]

Backed out diagnostic patch:
 https://hg.mozilla.org/integration/mozilla-inbound/rev/6f3a32b65985