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

RESOLVED FIXED in mozilla1.8alpha6

Status

()

defect
P1
normal
RESOLVED FIXED
15 years ago
9 months ago

People

(Reporter: bugzilla, Assigned: bzbarsky)

Tracking

({testcase})

Trunk
mozilla1.8alpha6
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(3 attachments, 3 obsolete attachments)

Reporter

Description

15 years ago
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...
Reporter

Comment 1

15 years ago
Reporter

Comment 2

15 years ago
Posted file Minimized testcase (obsolete) —
100% reproducible testcase using hyatts javascript trick. 

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

Comment 3

15 years ago
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...
Posted patch Patch (obsolete) — Splinter Review
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).
Attachment #167975 - Flags: superreview?(roc)
Attachment #167975 - Flags: review?(bernd_mozilla)

Comment 9

15 years ago
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.
Posted 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-

Updated

15 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Bug 276954 filed on the issue mentioned in comment 12.
Blocks: 275917
Reporter

Comment 18

14 years ago
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 ago14 years ago
Resolution: --- → FIXED

Comment 20

13 years ago
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.

Updated

9 months ago
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.