20468 - Large Blank Areas in text Layout.

Status: VERIFIED WORKSFORME

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Description

[Paul Hartlipp]

I am using Mozilla Milestone 11. The salon site has fixed width text margins and
under netscape a horizontal slide bar appears which allows the page to be move
from side to side. In some cases it seems the text becomes too narrow to fit
within the columns set up by Mozilla and there are blank areas in the articles.
I have the default "Panels" set up so the "My Panels" panel in on the left hand
side. There won't be much room.

This site also traps Mozilla easily.

Good Luck!

Comment 1

[troy]

I'm consistently hitting an assert in nsFrame::AppendFrames.

What's happening is that we get notified by the content sink that we have
appended content and we create frames and then try and append them to the parent
frame.

The trouble is that the parent frame is a nsHTMLFrameOuterFrame which doesn't
implement AppendFrames() (and hence the assert).

The real issue is that there's an inner frame (nsHTMLFrameInnerFrame) that
actually does the work. It should be the frame that gets the AppendFrames()
call and it should be the parent frame of the newly created frames.

Actually the inner frame seems to be a leaf so I;'m not sure who should get the
newly created frames.

The content object is an IFRAME

There needs to be some changes to the frame construction code to get this
working properly.

The reason we see the problem now is that with the new content sink changes we
generate content appended notifications where previously we didn't

Re-assigning to pollmann. Eric, we'll need to discuss this

NTDLL! 77f9d715()
nsDebug::PreCondition(const char * 0x02342d84, const char * 0x02342d78, const
char * 0x02342d4c, int 301) line 266 + 13 bytes
nsFrame::AppendFrames(nsFrame * const 0x00f50ea8, nsIPresContext * 0x00ee19f0,
nsIPresShell & {...}, nsIAtom * 0x00000000, nsIFrame * 0x00f5a4a8) line 301 + 35
bytes
FrameManager::AppendFrames(FrameManager * const 0x01e33d08, nsIPresContext *
0x00ee19f0, nsIPresShell & {...}, nsIFrame * 0x00f50ea8, nsIAtom * 0x00000000,
nsIFrame * 0x00f5a4a8) line 607
nsCSSFrameConstructor::AppendFrames(nsIPresContext * 0x00ee19f0, nsIPresShell *
0x01e33750, nsIFrameManager * 0x01e33d08, nsIContent * 0x00f4cd34, nsIFrame *
0x00f50ea8, nsIFrame * 0x00f5a4a8) line 5381 + 30 bytes
nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x01e336b0,
nsIPresContext * 0x00ee19f0, nsIContent * 0x00f4cd34, int 4) line 5562
StyleSetImpl::ContentAppended(StyleSetImpl * const 0x01e33600, nsIPresContext *
0x00ee19f0, nsIContent * 0x00f4cd34, int 4) line 937
PresShell::ContentAppended(PresShell * const 0x01e33758, nsIDocument *
0x01e1f970, nsIContent * 0x00f4cd34, int 4) line 2084 + 46 bytes
nsDocument::ContentAppended(nsDocument * const 0x01e1f970, nsIContent *
0x00f4cd34, int 4) line 1551
nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x01e1f970, nsIContent *
0x00f4cd34, int 4) line 1041
HTMLContentSink::NotifyAppend(nsIContent * 0x00f4cd34, int 4) line 3523
SinkContext::CloseContainer(const nsIParserNode & {...}) line 1262
HTMLContentSink::CloseContainer(HTMLContentSink * const 0x00f1cd40, const
nsIParserNode & {...}) line 2587 + 15 bytes
CNavDTD::CloseContainer(const nsIParserNode * 0x00f4cbd8, nsHTMLTag
eHTMLTag_iframe, int 0) line 2840 + 31 bytes
CNavDTD::CloseContainersTo(int 7, nsHTMLTag eHTMLTag_iframe, int 0) line 2873 +
20 bytes
CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_iframe, int 0) line 2962 + 20
bytes
CNavDTD::HandleEndToken(CToken * 0x01dee808) line 1561 + 20 bytes
CNavDTD::HandleToken(CNavDTD * const 0x00f9a438, CToken * 0x01dee808, nsIParser
* 0x00ee48a8) line 738 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x00f9a438, nsIParser * 0x00ee48a8,
nsITokenizer * 0x01e33e88, nsITokenObserver * 0x00000000, nsIContentSink *
0x00f1cd40) line 529 + 20 bytes

Comment 2

[troy]

*** Bug 21156 has been marked as a duplicate of this bug. ***

Comment 3

[Eric Pollmann]

Thanks for the Dup Troy, you are a bugzilla monster.  :)

Comment 4

[Eric Pollmann]

Marking this M13, hey, I'm hopeful.  :)

Comment 5

[Eric Pollmann]

Triaged to M14

Comment 6

[Gervase Markham [:gerv]]

WORKSFORME in 2000012208 (Win32), and M12 for that matter (at least, as far as 
I can tell given the somewhat vague description). If someone can confirm we 
aren't hitting this assert any more, we can mark this as WORKSFORME...

Gerv

Comment 7

[Eric Pollmann]

Hmm, I can't reproduce this either.  In fact, I went to the bug that was marked
a dup of this one and could not access the test case.

I'm going to mark this WORKSFORME but will be sending Troy an email to see if he
remembers what the problem was to see if we can fix it anyway.

Comment 8

[Chris Petersen]

With the Feb 01 build (20000020108), i'm not able to reproduce this problem. 
Marking verified works for me.