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

RESOLVED FIXED

Status

()

--
minor
RESOLVED FIXED
17 years ago
12 years ago

People

(Reporter: ericweb, Unassigned)

Tracking

({testcase})

Trunk
x86
All
testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
Reporter, does Reload cause this problem to occur? Have you found a testcase?

Updated

17 years ago
Priority: -- → P4
Target Milestone: --- → Future
(Reporter)

Comment 2

16 years ago
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.

Comment 3

16 years ago
Reporter, does the problem occur if you load the file locally?
and can you produce a testcase?

Comment 4

16 years ago
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future

Updated

16 years ago
Blocks: 200047

Comment 5

15 years ago
Created attachment 134478 [details]
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.

Comment 6

15 years ago
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.  

Updated

15 years ago
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)

Comment 7

15 years ago
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
(Reporter)

Comment 8

15 years ago
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.

Comment 10

14 years ago
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 → ---
Created attachment 170323 [details]
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
Last Resolved: 12 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.