Closed Bug 145111 Opened 18 years ago Closed 13 years ago

Nested shrink-to-fit does not use the available width

Categories

(Core :: Layout: Positioned, defect, minor)

x86
All
defect
Not set
minor

Tracking

()

RESOLVED FIXED

People

(Reporter: ericweb, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(2 files)

Using Mozilla RC2 on WinXP Pro.

There is a very infrequent bug in which an HTML table will initially lay out in
such a way that the cells do not line up in columns as expected. Shift-reload
causes the page to lay out correctly.

The document on which I see this bug is an HTML page that was output from
Microsoft Excel. Unfortunately I can't attach the document to this public bug
report because it is our internal employee phone book.

I just saw this today using Mozilla RC2 on WinXP Pro, but I recall seeing the
same problem a long time ago in earlier Mozilla builds running on WinME. At that
time I thought it was an artifact of running low on memory due to having many
windows open, but today it occurred with only five Mozilla, 3 Excel, and 1 AIM
window open on a Dell Latitude C600 with 256M of RAM. This is a very, very
infrequent problem, however it's real. Marking Severity minor and not nominating
for a milestone at this time.

Next time I see this I'll remember to take a screen shot and then edit it to
remove the company confidential information. In the meantime, imagine a table in
which each cell takes up as much horizontal space as it needs to hold its own
contents, but not more, with no cross-row coordination of the cells into columns
as expected. Therefore every row lays out its cells independently. This creates
a table that's unreadable and unusable for practical purposes.
Reporter, does Reload cause this problem to occur? Have you found a testcase?
Priority: -- → P4
Target Milestone: --- → Future
FYI: Saw this again on the same confidential phone book doc in Moz 1.3b. Didn't
think to capture screen shot. Will try to create nonconfidential test case if
time allows.
Reporter, does the problem occur if you load the file locally?
and can you produce a testcase?
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
Blocks: 200047
Attached file Testcase #1 (TABLE)
The table cells in this document do not align vertically in Mozilla Firebird
0.7 and Mozilla Suite 1.4, or in Mozilla Composer 1.4.
Further to my earlier comment, the issue seems to be related to the 'position:
absolute' in .main-outer and .main.  If one of these is removed, the columns are
aligned correctly.  
Keywords: testcase
Summary: table cells don't line up in columns on first display; shift-reload fixes problem → cells don't line up on first display; shift-reload fixes problem (table nested in 2 abs. pos boxes)
This is the currently the only major bug I notice in everyday use. On several
pages I find that a table layout renders incorrectly until the page is reloaded.
Examples include:
http://success.shoreline.edu/ebbtide/archive/v39/11/ - Table cell overflows
http://www.royalbarrel.com/portfolio.php - Thumbnails should run in two columns
Just confirming I'm still seeing this on XP SP1 with Moz 1.7 [Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514] using same darn
internal phonbook doc created by Excel.
I think this is already fixed somehow.
I can't see the bug with the testcase, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050103
Firefox/1.0+
I can see the bug, using Mozilla1.4 (and Mozilla1.7), though.
The rendering has changed even more with this testcase, it is now rendering the
same as Opera7.53, which - I think - is correct.
Mats, didn't you fix this in bug 201897 ?
(In reply to comment #10)
> Mats, didn't you fix this in bug 201897 ?

Partly, the cells now line up correctly and there is no incr. reflow problem.
The remaining issue is the width.
The problem, I think, is that the "available width" is not passed down correctly
in a nested shrink-to-fit situation (the testcase works correctly if you remove
the "main-outer" DIV).

The remaining issue is not a table problem per se.
Assignee: core.layout.tables → nobody
No longer blocks: 200047
Component: Layout: Tables → Layout: R & A Pos
Depends on: 275179
OS: Windows XP → All
Priority: P4 → --
QA Contact: madhur → core.layout.r-and-a-pos
Summary: cells don't line up on first display; shift-reload fixes problem (table nested in 2 abs. pos boxes) → Nested shrink-to-fit does not use the available width
Target Milestone: Future → ---
Attached file Testcase #2 (DIV)
Attachment #134478 - Attachment description: Testcase illustrating this issue → Testcase #1 (TABLE)
Actually, I think the current rendering is correct and that I was wrong in
comment 11.  There is nothing in CSS 2.1 AFAICT that says available width
should be "inherited" like that.
http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width

The containing block is "main-outer" and it has width:0, thus the
inner abs.pos. block "main" will be sized to its minimum width.

-> FIXED (by bug 201897)
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: 201897
Resolution: --- → FIXED
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.