useless horizontal scrollbar on ynet.co.il front page (with nested tables and table-layout: fixed)

RESOLVED FIXED

Status

()

RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: uriber, Assigned: dholbert)

Tracking

(Depends on: 1 bug, {regression, testcase})

Trunk
regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
Created attachment 259326 [details]
testcase

Ynet's front page now has a horizontal scrollbar that lets you scroll a very long way to the right - although there's nothing to see there.

This regressed between 2007-02-18 and 2007-02-19. Perhaps by the patch for Bug 366865?

The attached testcase shows that this involves tables with table-layout: fixed nested inside an outer table (the testcase also displays the issues described in bug 364989). Note that minor changes to the testcase (such as adding borders on the tables) can cause the scrollbar to disappear - which is why I couldn't reduce it further.

This was first reported by Dror on the mozilla.co.il forums: http://www.mozilla.org.il/board/viewtopic.php?p=22660#22660
(Reporter)

Updated

11 years ago
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
(Assignee)

Comment 1

11 years ago
This bug's testcase triggers a bunch of assertions and other scary messages on my machine.  Here they are, with duplicates removed. (Note: these aren't not in chronological order -- I piped them thru "sort|uniq" to screen for duplicates)

This bug's testcase triggers a bunch of assertions and other scary messages.  Here they are, with duplicates removed. (Note: these aren't not in chronological order -- I piped them thru "sort|uniq" to screen for duplicates)

###!!! ASSERTION: assigned width smaller than min: 'col_width >= colFrame->GetMinCoord()', file /scratch/work/builds/trunk.07-08-28.10-50/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 965
###!!! ASSERTION: bad width: 'Not Reached', file /scratch/work/builds/trunk.07-08-28.10-50/mozilla/layout/generic/nsLineLayout.cpp, line 180
###!!! ASSERTION: didn't subtract all that we added: 'space == 0 && ((l2t == FLEX_PCT_LARGE) ? (-0.001f < basis.f && basis.f < 0.001f) : (basis.c == 0))', file /scratch/work/builds/trunk.07-08-28.10-50/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 977
###!!! ASSERTION: shouldn't use unconstrained widths anymore: 'availableWidth != NS_UNCONSTRAINEDSIZE', file /scratch/work/builds/trunk.07-08-28.10-50/mozilla/layout/generic/nsHTMLReflowState.cpp, line 302
###!!! ASSERTION: shouldn't use unconstrained widths anymore: '(mFrameType == NS_CSS_FRAME_TYPE_INLINE && !frame->IsFrameOfType(nsIFrame::eReplaced)) || frame->GetType() == nsGkAtoms::textFrame || mComputedWidth != NS_UNCONSTRAINEDSIZE', file /scratch/work/builds/trunk.07-08-28.10-50/mozilla/layout/generic/nsHTMLReflowState.cpp, line 323
###!!! ASSERTION: this shouldn't happen anymore: 'NS_UNCONSTRAINEDSIZE != aComputedWidth && NS_UNCONSTRAINEDSIZE != aAvailWidth', file /scratch/work/builds/trunk.07-08-28.10-50/mozilla/layout/generic/nsHTMLReflowState.cpp, line 1920
###!!! ASSERTION: unconstrained widths no longer supported: 'aContainingBlockWidth != NS_UNCONSTRAINEDSIZE', file /scratch/work/builds/trunk.07-08-28.10-50/mozilla/layout/base/nsLayoutUtils.cpp, line 1636
###!!! ASSERTION: wrong case: 'colFrame->GetHasSpecifiedCoord() || colFrame->GetPrefCoord() == 0', file /scratch/work/builds/trunk.07-08-28.10-50/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 936
Block(td)(1)@0x8f23ce4: Init: bad caller: width WAS 1073741464(0x3ffffe98)
nsBlockReflowContext: TableOuter(table)(1)@0x8f238ec metrics=2147478144,1380!
WARNING: cell content 0x8f2370c has large width 2147478144 
OS: Mac OS X → All
Hardware: Macintosh → All
(Assignee)

Comment 2

11 years ago
The "didn't subtract all that we added" assertion already has a bug: Bug 371483

I'm pointing out this assertion in particular because it's pretty directly caused by one of the first things to go wrong in this bug: a situation in BasicTableLayoutStrategy::ComputeColumnWidths where
   colFrame->GetPrefCoord() == nscoord_MAX
Depends on: 371483
(Assignee)

Comment 3

11 years ago
See also bug 367673.
(Assignee)

Updated

11 years ago
Assignee: nobody → dholbert
(Assignee)

Comment 4

11 years ago
I posted an nscoord_MAX-checking patch on bug 367673, and it covers this bug as
well.
Status: NEW → ASSIGNED
Depends on: 367673
(Assignee)

Comment 5

11 years ago
Fixed by checkin for bug 367673.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Flags: in-testsuite?
(Assignee)

Comment 6

11 years ago
Created attachment 282459 [details] [diff] [review]
reftest
Attachment #282459 - Flags: review?(dbaron)
Comment on attachment 282459 [details] [diff] [review]
reftest

r+sr=dbaron.  Sorry for the delay.
Attachment #282459 - Flags: superreview+
Attachment #282459 - Flags: review?(dbaron)
Attachment #282459 - Flags: review+
(Assignee)

Comment 8

11 years ago
Checked in the reftest, with an indication that it currently fails (since yesterday) because of the fix for bug 368600.  This issue will be fixed when bug 400776 is addressed.
------------------

Checking in 374927-1.html;
/cvsroot/mozilla/layout/reftests/bugs/374927-1.html,v  <--  374927-1.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/layout/reftests/bugs/374927-1-ref.html,v
done
Checking in 374927-1-ref.html;
/cvsroot/mozilla/layout/reftests/bugs/374927-1-ref.html,v  <--  374927-1-ref.html
initial revision: 1.1
done
Checking in reftest.list;
/cvsroot/mozilla/layout/reftests/bugs/reftest.list,v  <--  reftest.list
new revision: 1.178; previous revision: 1.177
done
(Assignee)

Updated

11 years ago
Depends on: 400776
(Assignee)

Updated

11 years ago
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.