271422 - [FIXr]Main content appears in incorrect place, reload cures the problem

Status: RESOLVED FIXED

(Core :: Layout, defect, P1)

Description

[José Jeria]

Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041122

If you visit http://egon.blogharbor.com/ you will see that (sometimes) the main
content is not visible. In 1.7 branch the content appears, but at the bottom of
the floated menu to the left. 

Steps to reproduce:
1. go to http://egon.blogharbor.com/
2. Notice content missing, if not press reload a few times

Minimzed testcase coming...

Comment 1

[José Jeria]

Attachment: Screenshot of website with no content

Comment 2

[José Jeria]

Attachment: Minimized testcase

100% reproducible testcase using hyatts javascript trick. 

Orange menu should appear to the right of the menu div.

Comment 3

[José Jeria]

typo, should be "Orange content div should.."

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Even more minimized testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

bernd, any idea what's up here?  I do see the AppendFrames() call in
ContentAppended() happen, which puts the anonymous frames in place, but the
frame dump shows that the body's pseudo-block frame (kid of the pseudo-cell) has
no children....

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK, looks like the XXX comment I added in ConstructFrameByDisplayType in the
block case is relevant here.  Removing that part of the code makes this work...

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 167975 [details] [diff] [review]
Patch

Bernd, Robert, could you review?  The first two hunks are just fixes to prevent
asserts firing incorrectly on out-of-flow selects and fieldsets.  The last hunk
fixes this bug by removing the incorrect code that prevented a block kid of a
table that's not being constructed via ConstructTableForeignFrame from ending
up in the frame tree (because the old pseudo items had no frames, so looked
empty, even though it had nonempty childlists, and the block wasn't (and
shouldn't have been) placed in the child list of the new pseudo items).

Comment 9

[Bernd]

Boris why is this done for blockframes but not not the inline frames above (I am
just curious)

Comment 10

[Boris Zbarsky [:bzbarsky]]

Hmm... We shouldn't do it for inlines either.  I'll remove that.

The only reason it doesn't currently break for inlines because ConstructInline
doesn't place things in the frame list.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Updated patch

Note that ProcessInlineChildren does save the pseudo state, so we're ok there.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 168215 [details] [diff] [review]
Updated patch

possibly we should have an nsLayoutUtils method "GetRealFrameFor" (or something
like that) that gets the out of flow frame if the input frame is a placeholder

Comment 13

[Boris Zbarsky [:bzbarsky]]

I'll probably do that before checking in....

Comment 14

[Boris Zbarsky [:bzbarsky]]

Actually, I will do it as a separate patch.  We already have some "get real
frame" methods scattered about the tree, and consolidating them will be
something that would actually need review.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Attachment: Updated to layout reorg

Comment 16

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Bug 276954 filed on the issue mentioned in comment 12.

Comment 18

[José Jeria]

With trunk build 20050225, Windows XP I can still reproduce attachment 166866 [details].
Content div appears on the bottom. Reopening.

Comment 19

[Boris Zbarsky [:bzbarsky]]

The fix was for it not appearing at all.  That's what was reported as a trunk
bug in comment 0.

Appearing at the bottom is bug 148810.

Comment 20

[Alfred Peng]

The minimized testcase shows that "Content - this will appear at the bottom" on the top of the page. Is that correct?

Comment 21

[Boris Zbarsky [:bzbarsky]]

Alfred, see comment 19.