310089 - {inc}incremental reflow intrinsic width of max-width block inside table is too wide

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect)

Description

[Nils Maier [:nmaier]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8b5) Gecko/20050924 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8b5) Gecko/20050924 Firefox/1.4

No reflow done for max-width'ed elements inside table-cells.
Seems the newly restricted (computed) width is not considered correctly.

Assignment of maxWidth via js always fails.

While max-width in style fails only on first load (non-cached) and only on
particular document structures.

Seems to have to do with loading/rendering stages and or timeing? But Im not
familar with Gecko or moz source hacking.

Not sure if this is tables only. Or if eg. floats are affected as well. (not
tested further).

Attaching a testcase.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Nils Maier [:nmaier]]

Attachment: testcase for this thing.

Comment 2

[Nils Maier [:nmaier]]

And spamming some more :p

Just saw that loading this via file:// doesnt affect the first max-width table.
And the bugzilla version does not either.
Seems to be a timeing related issue, since I saw it displayed incorrectly when
using a somewhat slow server.

Having nglayout.initialpaint.delay = 0

Comment 3

[Adam Guthrie]

Dupe of bug 307866 / bug 308403?

Comment 4

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

No, those are about 'max-width' on table cells, not on blocks inside table cells.

Comment 5

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1 ID:2006120812 [cairo]

Seems fixed by reflow branch landing

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Adding in-testsuite? nomination per bz's request in m.d.t.l. Sorry for the bugspam.