313516 - [FIX]RecreateFramesForContent should flush

Status: RESOLVED FIXED

(Core :: Layout, defect, P1)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

Followup from bug 313440

RecreateFramesFor should probably flush the sink to avoid possible content duplication.

Comment 1

[Boris Zbarsky [:bzbarsky]]

biesi, do you recall why the patch for bug 1156 did:


992     // Need the following line before calling RecreateFramesFor
993     mozAutoDocUpdate upd(doc, UPDATE_CONTENT_STATE, PR_TRUE);
994 
995     PRUint32 numShells = doc->GetNumberOfShells();
996     for (PRUint32 i = 0; i < numShells; ++i) {
997       nsIPresShell* shell = doc->GetShellAt(i);
998       shell->RecreateFramesFor(thisContent);

(that is, why we did that first part)?  I seem to recall asking you to do it, but can't recall what the reason was, exactly...  I _think_ it was supposed to flush the sink, in which case it's not working now, of course.... ;)

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

quoting the relevant parts of the IRC discussion:
Mai 30 18:32:34 bz	biesi: RecreateFramesFor is idempotent under some assumptions
Mai 30 18:32:44 bz	biesi: the main one being that all content in the DOM has been notified for
Mai 30 18:33:04 bz	biesi: that is, that the sink has been flushed
Mai 30 18:33:36 bz	biesi: that's the benefit of the content state approach -- you get that for free
[...]
Mai 30 18:34:43 bz	biesi: so I'd try calling Begin/EndUpdate around your reframes

I believe that this was needed to fix this problem I had:
Mai 30 18:08:40 biesi	bz, would you have any idea why I would get two ObjectFrames for an <object>, one of them pretty misplaced on the screen as well as the frame tree?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, right.  And then I went and made CONTENT_STATE updates _not_ flush the sink... ;)

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

Comment 5

[Boris Zbarsky [:bzbarsky]]

Fixed.