Closed
Bug 260938
Opened 20 years ago
Closed 20 years ago
[fix] mozdev's pages' middle-column drops below left column
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: tom_b52, Assigned: roc)
References
()
Details
(Keywords: testcase)
Attachments
(2 files)
1.03 KB,
text/html
|
Details | |
11.99 KB,
patch
|
roc
:
review-
roc
:
superreview-
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040921 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040921 Visiting several projects in mozdev.org, the middle column renders below the lowest part of the left column (though remaining in the middle column) when you click on the middle column's "resources" navigation on top. (This navigation usually has "Home Mailing List Installation Source Code Members Screenshots" links). So it is like the left column becomes its own row. It will bounce back up if you resize or refresh the browser. Same error is in the 20040921 Firfox trunk nightly. However, these pages will render propperly in Linux/Mozilla 1.7.1, & had before in my Mozilla 1.7beta on Win98se. Looking at the HTML code, the mozdev pages look like a mish-mash of CSS columns & tables. The said "project-navigation" is contained in a table, which in turn is in <div id="main-content">. I checked several CSS 3-column examples at http://css-discuss.incutio.com/?page=ThreeColumnLayouts & I am unable to repeat the same mozdev rendering error. Reproducible: Always Steps to Reproduce: 1. visit http://vssdoclinks.mozdev.org/ 2. click on a link in "resources" navigation on top 3. middle column will drop 4. refresh/resize, midlle will return to the top Expected Results: render the middle column flush to the top
Comment 1•20 years ago
|
||
Possibly related to Bug 260442?
Comment 2•20 years ago
|
||
I´m duping this to bug 260963 as I´ve commented there a lot of numbers. broken : Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040916 working: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040911 broken Build ID 2004091605 major, as it is a highly visible regression. *** This bug has been marked as a duplicate of 260963 ***
Severity: minor → major
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Comment 3•20 years ago
|
||
minimal testcase made from http://www.mozdev.org/logs/top50.html 3 divs with visible borders to show what is going on.
Comment 4•20 years ago
|
||
I´m reopening this bug, as Bug 260963 is wfm now. Simple testcase attached: https://bugzilla.mozilla.org/attachment.cgi?id=160062&action=view Maybe it is related to Bug 260442, but I can´t test, as I can´t test on linux and don´t have a slashdot account.
Comment 5•20 years ago
|
||
Confirming based on testcase Bug 260963 comment 7 was showing a regression timeframe between BuildID 2004091105 working and BuildID 2004091306 broken http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-11+00%3A00&maxdate=2004-09-13+08%3A00&cvsroot=%2Fcvsroot maybe Bug 257216? Fix sundry block issues for columns. In particular, remove overflowing floats from the space manager before we compute the space manager's XMost and YMost to include in the block size. r+sr=dbaron"
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 6•20 years ago
|
||
This exposed some confusion about whether nsLineBox::mBreakType means break *before* the line or *after* the line. Turns out it's *before* the line for blocks and *after* the line for inlines. I added new methods in nsLineBox.h to make this explicit and changed the relevant code in nsBlockFrame to explicitly look for before or after breaking. This fixed the bug here.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Assignee | ||
Updated•20 years ago
|
Attachment #160089 -
Flags: superreview?(dbaron)
Attachment #160089 -
Flags: review?(dbaron)
Comment 7•20 years ago
|
||
thanks roc, for the fast action requesting blocking 1.8a4 would be nice if mozdev.org won´t show this bug with 1.8a4
Flags: blocking1.8a4?
thanks for looking into this (I'm the original bug-submitter). "would be nice if mozdev.org won´t show this bug with 1.8a4" IMHO, I'm glad it was caught early, as this bug may have grown worse in time. But it is funny I first noticed it on a moz site :)
Comment 9•20 years ago
|
||
I see this on Linux also. www.xulplanet.com is badly affected, too.
OS: Windows 98 → All
Comment 10•20 years ago
|
||
I assume fixing this bug would also fix some others from the list of Bug 261196, maybe Bug 261153 if you click a link, move a link Bug 260442 Form elements jump when form buttons pressed ( posting at slashdot!)
Summary: mozdev's pages' middle-column drops below left column → [fix] mozdev's pages' middle-column drops below left column
Updated•20 years ago
|
Flags: blocking1.8a4?
Reporter | ||
Comment 11•20 years ago
|
||
(In reply to comment #10) > I assume fixing this bug would also fix some others from the list of Bug 261196, > ...Bug 261153... Bug 260442 Yes, they all seem related, since I get the same behavor at mozdev.org
Assignee | ||
Comment 12•20 years ago
|
||
Comment on attachment 160089 [details] [diff] [review] fix minusing because this work is completely subsumed by the work in bug 209694.
Attachment #160089 -
Flags: superreview?(dbaron)
Attachment #160089 -
Flags: superreview-
Attachment #160089 -
Flags: review?(dbaron)
Attachment #160089 -
Flags: review-
Comment 13•20 years ago
|
||
Mozilla Windows Trunk Nightly Build Regression Window Pass: 2004091105 Fail: 2004091306
Comment 14•20 years ago
|
||
Fixed by bug 209694
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•