Closed Bug 271422 Opened 20 years ago Closed 20 years ago

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


(Core :: Layout, defect, P1)






(Reporter: bugzilla, Assigned: bzbarsky)




(Keywords: testcase)


(3 files, 3 obsolete files)

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

If you visit 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
2. Notice content missing, if not press reload a few times

Minimzed testcase coming...
Attached file Minimized testcase (obsolete) —
100% reproducible testcase using hyatts javascript trick. 

Orange menu should appear to the right of the menu div.
typo, should be "Orange content div should.."
Attachment #166866 - Attachment is obsolete: true
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....
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...
Attached patch Patch (obsolete) — Splinter Review
Component: Layout → Layout: Misc Code
Ever confirmed: true
QA Contact: core.layout → core.layout.misc-code
Comment on attachment 167975 [details] [diff] [review]

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).
Attachment #167975 - Flags: superreview?(roc)
Attachment #167975 - Flags: review?(bernd_mozilla)
Boris why is this done for blockframes but not not the inline frames above (I am
just curious)
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.
Attached patch Updated patch (obsolete) — Splinter Review
Note that ProcessInlineChildren does save the pseudo state, so we're ok there.
Attachment #167975 - Attachment is obsolete: true
Attachment #168215 - Flags: superreview?(roc)
Attachment #168215 - Flags: review?(bernd_mozilla)
Attachment #167975 - Flags: superreview?(roc)
Attachment #167975 - Flags: superreview-
Attachment #167975 - Flags: review?(bernd_mozilla)
Attachment #167975 - Flags: review-
Attachment #168215 - Flags: review?(bernd_mozilla) → review+
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
Attachment #168215 - Flags: superreview?(roc) → superreview+
I'll probably do that before checking in....
Assignee: nobody → bzbarsky
Priority: -- → P1
Summary: Main content appears in incorrect place, reload cures the problem → [FIXr]Main content appears in incorrect place, reload cures the problem
Target Milestone: --- → mozilla1.8alpha6
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.
Attachment #168215 - Attachment is obsolete: true
Blocks: 276053
Fixed on trunk.
Closed: 20 years ago
Resolution: --- → FIXED
Bug 276954 filed on the issue mentioned in comment 12.
Blocks: 275917
With trunk build 20050225, Windows XP I can still reproduce attachment 166866 [details].
Content div appears on the bottom. Reopening.
Resolution: FIXED → ---
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.
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
The minimized testcase shows that "Content - this will appear at the bottom" on the top of the page. Is that correct?
Alfred, see comment 19.
Product: Core → Core Graveyard
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.