413311 - [BC] borders do not react to dynamic CSS class changes of TRs

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Marcus Better]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008011704 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008011704 Minefield/3.0b3pre

Collapsed borders behave incorrectly when the style for TR elements is changed dynamically by script. The affected borders do not follow the CSS priority rules for collapsed borders. Sometimes only part of the border (e.g. the bottom border) is correctly updated.

The same DOM in a static HTML file is rendered correctly.


Reproducible: Always

Comment 1

[Marcus Better]

Attachment: Test case

For comparison, Konqueror gets this case right.

Comment 2

[Marcus Better]

Attachment: Test case with two rows and a border conflict

The bottom border of the second row is rendered correctly (blue). The right, left and top borders remain dotted red.

Comment 3

[Ryan Hickman]

CONFIRMED

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008012104 Minefield/3.0b3pre

vs.

Konqueror

This is not a regression, 2.0.0.11 reveals same issue.

Note the reporter is setting className via JS in body onLoad.

Comment 4

[Ryan Hickman]

Is it just me or should product be changed to "Firefox"? Hoping to flag for 3.0

Comment 5

[Marcus Better]

(In reply to comment #3)
> Note the reporter is setting className via JS in body onLoad.

The bug also shows if className is set at a later time. My original problem came up when working on a rich AJAX framework.

Comment 6

[Ryan Hickman]

Could someone please change product to Firefox so this can be flagged?

Comment 7

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

No.  It's in the correct product.

The Firefox 3 release ships with Gecko 1.9, so the *1.9 flags here correspond to the *firefox3 flags in the Firefox product.

Comment 8

[Ryan Hickman]

rgr, thanks David.

Comment 9

[Mike Schroepfer]

If this is not a regression from 200x than I'm moving to wanted list.  As in we'd love to fix it but will not block the release on it.

Comment 10

[Bernd]

This is not a regression, it simply did never work as it was never implemented. There is no code that would react on a border style change. It should trigger a new border collapse computation via SetBCDamageArea. If you search for this function you will find that it is only used for frame manipulations (adding/removing frames).

Comment 11

[Bernd]

And it does not work if you set on any of the table frames (luckily IE7 renders the test case as we do)

Comment 12

[Bernd]

Boris: is there a way to detect during reflow that the border style has changed?

Comment 13

[Boris Zbarsky [:bzbarsky]]

You could set a bit in DidSetStyleContext(), but that would only tell you that _some_ style has changed, not what style.

I suppose DidSetStyleContext could compare the new border style to the old one if the old one is stored somewhere outside the style context.

Another option is to add an additional mechanism for the frame to be notified of this change (another change hint, basically), I guess.  It'd be pretty hacky.

Comment 14

[Bernd]

I think this is not feasible/desirable in the 1.9 time frame. If we start to react on the dynamic changes we would need a full round of fuzzing + bug squeezing in a very fragile code (euphemism for messy code).

Comment 15

[Bernd]

and btw this is a dupe imho of bug 258377

Comment 16

[Bernd]

Can this please be retriaged, I am against putting this into the 1.9 see comment 14.

Comment 17

[Damon Sicore (:damons)]

Taking this off the blocker list per comment #16 (and comment #14).

Thanks, Bernd.

Comment 18

[Bernd]

fixed by checkin for bug 258377