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...
typo, should be "Orange content div should.."
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...
Status: UNCONFIRMED → NEW
Component: Layout → Layout: Misc Code
Ever confirmed: true
QA Contact: core.layout → core.layout.misc-code
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).
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.
Note that ProcessInlineChildren does save the pseudo state, so we're ok there.
Attachment #167975 - Attachment is obsolete: true
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
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
With trunk build 20050225, Windows XP I can still reproduce attachment 166866 [details]. Content div appears on the bottom. Reopening.
Status: RESOLVED → REOPENED
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.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago → 14 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.
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.