360065 - [reflow branch] Incorrect layout of deviantArt galleries

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[William Swanson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20061107 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20061107 Minefield/3.0a1

The image galleries deviantArt.com do not display properly on the reflow branch. The first image appears in the correct location, but the remaining images pile up off the edge of the screen. On the trunk builds, the image appear next to each other in several rows.

Reproducible: Always

Steps to Reproduce:
1. Visit any gallery page at deviantArt.com using the latest reflow branch build. http://browse.deviantart.com/customization/skins/web/firefox/ would work.
Actual Results:  
All the images except the first one appear piled up on the edge of the gallery.

Expected Results:  
The images appear next to each other in multiple columns and multiple rows.

The deviantArt galleries use a <span> with {display: table-cell; width: 205px;} inside a <div> with {display: inline;}. For some reason, the width of the <div> is the width of its parent, rather than the 205px width of its content. This forces the remaining gallery images over the edge.

Comment 1

[William Swanson]

Attachment: Reduced test case showing the incorrect behavior

Comment 2

[Mats Palmgren (inactive)]

The front page is also affected so changing URL to http://www.deviantart.com
(which is #63 on Alexa's Top100 English site list)

Comment 3

[Mats Palmgren (inactive)]

It looks like a table related problem:

TableOuter(div)(1)@0xf1aa30 {0,-14,8400,560} ... pst=:-moz-table-outer<
  Table(div)(1)@0xf1aab0 {0,0,2688,560} ... pst=:-moz-table<

The outer table frame should have the width of the inner in this case, yes?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Something more closely resembling a reduced testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

So the basic problem is that this is falling into the case described by roc in bug 297537 comment 8 and going forward.

So when we call ComputeSize, aShrinkWrap is false (since the table is a block-level as far as the reflow state is concerned).

I suppose we could add a nasty hack here for the time being, until we actually implement inline table properly....

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Said nasty hack...

Comment 7

[Boris Zbarsky [:bzbarsky]]

The other option is to put the nasty hack into nsTableOuterFrame, of course.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: reftest for this

Comment 9

[Boris Zbarsky [:bzbarsky]]

Fixed on reflow branch; filed bug 361352 on fixing this the "right" way with inline-table.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Merged reftest

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 247933 [details] [diff] [review]
Merged reftest

Probably better to use blue/purple rather than red/green (which imply fail/pass). 

r=dbaron

Comment 12

[Boris Zbarsky [:bzbarsky]]

Checked in the test with that change.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Er, actually, shouldn't the test be marked as passing now that it passes?  (I just got an "UNEXPECTED PASS" on this test.)

Comment 14

[Boris Zbarsky [:bzbarsky]]

Er... it's not guaranteed to pass until we implement inline-table.  It would certainly have failed on my machine -- the vertical positioning was different by 1-2 pixels between the test and the ref.

Maybe we should comment the test out until inline-table works.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oh, I was testing in my tree where I'm implementing inline-table. :-)