Summary: | Canvas element breaks when RenderObject creation is deferred by external CSS | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Martin Dittus <webcore> | ||||||
Component: | Layout and Rendering | Assignee: | Darin Adler <darin> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | dacarson, triptych | ||||||
Priority: | P2 | Keywords: | HasReduction | ||||||
Version: | 412 | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
Attachments: |
|
Description
Martin Dittus
2005-09-08 05:27:59 PDT
Created attachment 3814 [details]
Three simple test cases
Attaching three simple test cases:
test 1 - simple page with external CSS, and all canvas drawing done inline
test 2 - simple page without external CSS, and all canvas drawing done inline
test 3 - simple page with external CSS, and all canvas drawing done via
onload()
Both Safari 2.0.1 (412.5) and the most recent WebKit CVS version show
the same behavior:
test 1 doesn't work (blank canvas)
test 2 works (canvas filled black)
test 3 works (canvas filled black)
Just to be sure I checked with a recent Firefox release, and all three
test cases worked fine (canvas filled black).
Confirmed, good testcases. Reassigning to webkit-unassigned I believe the root cause of this problem is the same as: http://bugzilla.opendarwin.org/show_bug.cgi?id=6291 ie the render object has not been constructed yet, and as such, there is bitmap to paint onto. *** Bug 6291 has been marked as a duplicate of this bug. *** Details copied from 6291: The problem seems to be that the Canvas render object (RenderCanvasImage) has not been created yet, although there is a valid DOM element. By memory, render objects are not created until they are attached to the DOM tree. I believe this is because the engine does not know how to provide the style information needed to create a render object until it knows it's location within the tree. So, although the getContext function will return with a valid canvas context, no methods on that object will succeed until it is attached to the DOM. I am not sure what can be done about this. We basically need the capability to stall script when it ends up needing style information. Assuming improvements do not occur in this area (i.e., the JS engine), I'll probably be changing the engine to simply block on scripts until stylesheets have fully loaded. Hyatt and I talked about this recently and we realized that the right way to fix this is to move the canvas bitmap buffer from the render object into the DOM object. I'll probably be doing that after I land the fix for bug 7749, although the fix for that will not resolve this. Created attachment 7592 [details]
patch, including detailed change log and layout test
Comment on attachment 7592 [details]
patch, including detailed change log and layout test
While it does look like this change breaks backwards compatibility for <canvas> elements without any specified width or height, a) I don't think anyone is relying on that and b) following the standard is way better.
r=me
|