Closed Bug 328541 Opened 18 years ago Closed 18 years ago

iframe drawn to canvas doesn't show immediately preceding DOM changes

Categories

(Core :: Graphics: Canvas2D, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: myk, Assigned: roc)

Details

(Keywords: fixed1.8.1, testcase)

Attachments

(2 files)

If a script modifies the DOM of a document in an iframe (f.e. by adding an element via appendChild) and then immediately draws the iframe onto a canvas, the canvas doesn't reflect the modification.  However, if the script instead draws the iframe onto the canvas via a setTimeout() call, even one with a delay of zero milliseconds, the canvas does reflect the modification.  Seems like it should reflect the modification in both cases.  Testcase to be attached shortly.
Interesting.. not sure where I'd look, bz or roc probably have an idea.
Attached file testcase
Here's a testcase that demonstrates the problem.  It's a XUL doc with an iframe, a canvas, and two buttons.  The first button appends a text node to the iframe and then immediately draws the iframe to the canvas.  The second button appends a text node to the iframe and then sets a timeout to draw the iframe to the canvas.

If you press the first button, the text "sample text" appears in the iframe but doesn't get drawn to the canvas, demonstrating the bug.  If you instead press the second button, that text appears in the iframe and does get drawn to the canvas, demonstrating the correct behavior.

Note that you have to load this as chrome to satisfy security requirements.
I think we need to do some flushing in drawWindow before we paint.
Yeah.  Before actually painting you want to call FlushPendingNotifications(Flush_Layout) on the relevant document.

Note that doing that can destroy any presshells or prescontexts (and when XUL is involved can actually destroy docshells) that are around.  So if you're holding any pointers to any of the above objects before you flush, you want to reget them.  I recommend flushing before you start looking for any of those.  ;)
Keywords: testcase
Attached patch fixSplinter Review
As suggested --- this fixes it.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #213277 - Flags: superreview?(bzbarsky)
Attachment #213277 - Flags: review?(bzbarsky)
Attachment #213277 - Flags: superreview?(bzbarsky)
Attachment #213277 - Flags: superreview+
Attachment #213277 - Flags: review?(bzbarsky)
Attachment #213277 - Flags: review+
checked in. We should probably take this on 1.8.1 branch too.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Attachment #213277 - Flags: approval-branch-1.8.1?
Works great; thanks guys.
Status: RESOLVED → VERIFIED
Comment on attachment 213277 [details] [diff] [review]
fix

a=shaver for branch.
Attachment #213277 - Flags: approval-branch-1.8.1? → approval-branch-1.8.1+
Checked into 1.8 branch.
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: