Closed Bug 374927 Opened 18 years ago Closed 17 years ago

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

Categories

(Core :: Layout: Tables, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: uriber, Assigned: dholbert)

References

(Depends on 1 open bug, )

Details

(Keywords: regression, testcase)

Attachments

(2 files)

Attached file 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
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
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
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
See also bug 367673.
Assignee: nobody → dholbert
I posted an nscoord_MAX-checking patch on bug 367673, and it covers this bug as well.
Status: NEW → ASSIGNED
Depends on: 367673
Fixed by checkin for bug 367673.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
Attached patch reftestSplinter Review
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+
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
Depends on: 400776
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: