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

VERIFIED FIXED

Status

()

VERIFIED FIXED
13 years ago
13 years ago

People

(Reporter: myk, Assigned: roc)

Tracking

({fixed1.8.1, testcase})

Trunk
x86
Linux
fixed1.8.1, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 2

13 years ago
Created attachment 213141 [details]
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.  ;)

Updated

13 years ago
Keywords: testcase
Created attachment 213277 [details] [diff] [review]
fix

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
Last Resolved: 13 years ago
Resolution: --- → FIXED
Attachment #213277 - Flags: approval-branch-1.8.1?
(Reporter)

Comment 7

13 years ago
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.