Closed Bug 26727 Opened 25 years ago Closed 25 years ago

[dogfood] layout not rendering content in editor

Categories

(Core :: Layout, defect, P3)

PowerPC
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mozeditor, Assigned: troy)

Details

I see this on mac but suspect it may be x-platform:

This happens in both opt and debug, but you will need to debug to follow my 
directions below.

Open the editor.  Type:

This in line 1
This is line 2
This is line 3


Place caret at beginning of second line of text.  Hit backspace.

Observe that the contents of line 2 entirely dissapear.  Now choose "Dump 
Content" from the debug menu.  Observe that the content looks correct: line 2 got 
pulled up into the same text node as line 1.  But it isn't rendering.

I recently changed the editor to use the reflow batching Nisheeth implemented.  I 
dont know if this problem is related.
marking dogfood.
Keywords: dogfood
Summary: layout not rendering content in editor → [dogfood] layout not rendering content in editor
It's not a painting problem, because covering the window and exposing it doesn't 
fix it, and resizing the window doesn't fix it either

It looks to be reflow command coalescing related, because I see the text frame's 
ContentChanged() function get called, and it asks its parent block to reflow it. 
The block sees that it already has a dirty child and so it cancels the existing 
reflow command and tell its parent frame it is dirty and needs to be reflowed

The text frame's Reflow() function never gets called which is why things don't 
display properly
I don't it's bacause of reflow command coalescing. It looks like it's just a bug 
in the block frame's MarkLineDirty() code. I also thought it was suspicious that 
it doesn't actually mark aLine "dirty" in the case where it marks the previous 
line dirty.

If I change MarkLineDirty() to always mark aLine dirty (the safe thing to do), 
then everything is fine

It looks like what happened is that changing the text frame code to call 
ReflowDirtyChild() exposed the problem in MarkLineDirty().
It looks like what happens is the second line of text becomes "This is line 
1This is line 2". It's not marked dirty; instead the first line is marked 
dirty. Then the first line is deleted because it's one and only child frame is 
removed.

Because the first line ends in a BR there's no reason to mark the second line 
dirty and so we never reflow the second line (now the first line)
Changed MarkLineDirty()
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed in the Feb 18th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.