622212 - HTML5 Canvas text not working with inline frame

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

[Eric Rowell]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.19 Safari/534.13
Build Identifier: Firefox 3.6.13

In my site, the HTML5 Canvas works correctly when inside an inline frame for every browser including Firefox, with the exception of text.  When text is displayed on an HTML5 canvas inside an inline frame, Firefox throws the following error:

Component returned failure code: 0x0004005 (NS_ERROR_FAILURE)

Reproducible: Always

Steps to Reproduce:
1. open up the webpage listed above
2.
3.

Comment 1

[Alice0775 White]

Confirmed on Minefield4.0b9pre too.
Mozilla/5.0 (X11; Linux i686; rv:2.0b9pre) Gecko/20101228 Firefox/4.0b9pre ID:20101228030339

And the text will appear if I execute reload of iframe. 
Right click on yhe iframe > This Frame > Reload Frame

Comment 2

[Alice0775 White]

Attachment: sample iframe

Comment 3

[Alice0775 White]

Attachment: sample (Maybe works properly)

Comment 4

[Alice0775 White]

The above attachment 500467 [details] sample works properly.

It is strange.

Comment 5

[Boris Zbarsky [:bzbarsky]]

The testcase in this bug worksforme.

The testcase in the url field does fail, which is a bit odd.  But the underlying issue is that canvas will fail to draw text if it has no style, but doesn't do the flushing needed to ensure that its style is up to date, right?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Oh, and the oddness is that we currently flush layout before firing onload, so all the styles should be up to date already in this case.

Comment 7

[Eric Rowell]

Thank you guys so much for looking at this!!!!  You are indeed correct, I set up a straight forward test case with HTML5 Text rendering inside of an IFRAME, and it works great in Firefox.  There's definitely something odd going on though when opening up the URL mentioned above in Firefox.  There may be some sort of weird conflict occurring with the canvas.  I'll continue to investigate.

Comment 8

[Boris Zbarsky [:bzbarsky]]

So on trunk we only flush layout on the presshell, which wouldn't flush it on the parent doc.  So I can see how this issue could happen there.  But the 3.6 behavior still mystifies me.

Alice0775, do you think you can create a minimal-ish testcase that still shows the problem on 3.6?

Comment 9

[Alice0775 White]

Attachment: reduced testcase

Umm, I do not understand why the page set style "display:none" to body.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Aha!  Yeah, that would most certainly do it; the pre-onload flush won't create layout objects due to the display:none, and then the style change happens async.

But even worse, the onload for the subframe fires before the onload for the main page, guaranteed.  So at that point the body is guaranteed to be display:none, and adding more flushing in the canvas code wouldn't help with that.

The only thing that _would_ help is if we decoupled canvas text rendering from having layout objects available, which means decoupling style information from the preshell and hooking it up to the document instead.  But note that styles depend on the size of the iframe (due to media queries), which depends on the presence of a layout object for the iframe, obviously.  So in general the styles used for the text will be wrong in this situation if we ever make it work.

So I would somewhat prefer making the spec say that in this situation an exception is thrown, since there's no way to reliably render the text.

dbaron, vlad, thoughts?

Comment 11

[Eric Rowell]

That is indeed the problem!  FYI, I've removed the "display:none" style from the body in the URL listed above, and now the HTML5 Text renders correctly from inside the inline frame.  Thank you guys!