Last Comment Bug 260938 - [fix] mozdev's pages' middle-column drops below left column
: [fix] mozdev's pages' middle-column drops below left column
: testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 All
: -- major with 1 vote (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
: Jet Villegas (:jet)
Depends on: 209694
Blocks: 261196
  Show dependency treegraph
Reported: 2004-09-22 03:40 PDT by tomByrer
Modified: 2004-11-26 01:11 PST (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (1.03 KB, text/html)
2004-09-25 10:48 PDT, Hermann Schwab
no flags Details
fix (11.99 KB, patch)
2004-09-25 13:49 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
roc: review-
roc: superreview-
Details | Diff | Splinter Review

Description tomByrer 2004-09-22 03:40:58 PDT
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, 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 & I am unable to repeat
the same mozdev rendering error.

Reproducible: Always
Steps to Reproduce:
1. visit
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 Christopher Curzio 2004-09-22 04:17:53 PDT
Possibly related to Bug 260442?
Comment 2 Hermann Schwab 2004-09-22 15:24:01 PDT
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 ***
Comment 3 Hermann Schwab 2004-09-25 10:48:51 PDT
Created attachment 160062 [details]

minimal testcase made from
3 divs with visible borders to show what is going on.
Comment 4 Hermann Schwab 2004-09-25 10:58:08 PDT
I´m reopening this bug, as Bug 260963 is wfm now.
Simple testcase attached:

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 Hermann Schwab 2004-09-25 11:06:48 PDT
Confirming based on testcase
Bug 260963 comment 7 was showing a regression timeframe between BuildID
2004091105 working and BuildID 2004091306 broken

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"
Comment 6 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-09-25 13:49:17 PDT
Created attachment 160089 [details] [diff] [review]

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.
Comment 7 Hermann Schwab 2004-09-25 14:04:29 PDT
thanks roc, for the fast action

requesting blocking 1.8a4
would be nice if won´t show this bug with 1.8a4
Comment 8 tomByrer 2004-09-25 22:23:34 PDT
thanks for looking into this (I'm the original bug-submitter).

"would be nice if 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 Stefan Borggraefe 2004-09-26 23:55:11 PDT
I see this on Linux also. is badly affected, too.
Comment 10 Hermann Schwab 2004-09-27 15:50:41 PDT
I assume fixing this bug would also fix some others from the list of Bug 261196,
Bug 261153 if you click a link, move a link
Bug 260442 Form elements jump when form buttons pressed ( posting at slashdot!)
Comment 11 tomByrer 2004-09-28 22:58:43 PDT
(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
Comment 12 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-10-02 21:09:00 PDT
Comment on attachment 160089 [details] [diff] [review]

minusing because this work is completely subsumed by the work in bug 209694.
Comment 13 Ronald Tilby 2004-10-08 14:42:22 PDT
Mozilla Windows Trunk Nightly Build Regression Window
Pass: 2004091105
Fail: 2004091306
Comment 14 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-11-26 00:54:05 PST
Fixed by bug 209694

Note You need to log in before you can comment on or make changes to this bug.