473736 - Table cells with collapsed border, change class with Javascript, gets width and color wrong

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect, P4)

Description

[Colin Fine]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3

In a table with border-collapse:collapse, I have css rules that give td's a 1px silver border, but td's with class 'special' a 2px blue border.

If a cell has the class in the original page, it is rendered correctly, even if the class is repeatedly removed and put back.

But if any other cell, which didn't originally have class 'special', is given the class, the border is displayed wrongly:

1. It is never 2px wide
2. Only some of the cell's border turn blue
3. In some cases, borders of other cells not adjacent to the picked one turn blue. 
 

Reproducible: Always

Steps to Reproduce:
1. Download the page from Pastie and go to it
2. Click on any cell
3.
Actual Results:  
Apart from the one cell which starts out bordered in blue, clicking on any cell turns some borders (on that and possibly other cells) to turn blue, but stay thin.
In no case does it turn all the borders of the clicked cell blue.
The behaviour is consistent.

Expected Results:  
It should turn all the borders of the picked cell blue, or turn them back to silver when clicked again (unless an adjacent cell is 'special', in which case the common border should stay blue. 

http://www.w3.org/TR/CSS21/tables.html#border-conflict-resolution

Note that the 'special' border is thicker, so it should always 'win'.

Comment 1

[Mardeg]

Attachment: Example as a file

WFM in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 except the very bottom borders of cells clicked on the bottom row are only half as thick when clicked on after cells from the other rows are already blue, and I noticed it shifts down by a pixel when they are, which may explain that particular bug.

Comment 2

[Colin Fine]

Another observation: the cell which begins with class 'special' doesn't behave correctly either: removing the class changes the colour of its border, but not its width.

Comment 3

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090115 Minefield/3.2a1pre

The bottom line is redrawn correctly when I switch to another tab and switch back.

Comment 4

[T.J. Crowder]

I'm seeing similar behavior,although unlike Klassen it isn't correcting when switching between tabs.  Presumably the same underlying error, thought another test case would be helpful:
http://pastie.org/565153

In that test case, 'fullbox' cells have a full border, and 'partialbox' cells have only top, left, and right.  cell1 ("Originally Full") starts out as fullbox, cell2 ("Originally Partial") starts out as partialbox.  Initial draw is fine, but after swapping their classes with the supplied button the newly-fullbox cell has no bottom border.  I've also seen the opposite, where the cell that shouldn't have a bottom border keeps its previous one, but that's not happening in this example.

Comment 5

[luca.defeo]

This bug looks very similar to what I've recently found : dynamically changing table cell borders (from set to unset) on a border-collapsed table results in erratic repainting.

Here's a demo http://jsfiddle.net/defeo/L4jtw37r/

Click on some cells. After a few clicks borders will start going crazy.

Comment 6

[Ya-Chieh Wu (inactive)]

The attachment looks ok on FF 58.0a1 on mac OS.
I can see the blue border is wider than the sliver border.
I guess that we recently fixed the border rounded issue in Bug 895096 which could also fix this one.

As the comment 5, it does look that a issue but it doesn't look like that it relates to this bug's description.
I will close this bug as WFM by tomorrow if no one leaves concerns here.
And also, I will help to report the issue that was reporting on Comment 5.

Comment 7

[Marcia Knous [:marcia]]

If 58 is unaffected, we don't need to track this for release. When you close the bug out, please switch the tracking flag so it doesn't reflect "?". Thanks.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screencast of borders occasionally being half-width

(In reply to Mardeg from comment #1)
> the very bottom borders of cells clicked
> on the bottom row are only half as thick when [...]

I'm seeing this in some cases, too, as shown in this screencast.  I'm using latest Nightly on Linux. 58.0a1 (2017-10-26) (64-bit)


e.g. about 7 seconds in:
 - the cell with text "2px" (bottom center-left) has a bottom-border of the wrong thickness.
 - the cell with text "border" (bottom-right) has a bottom-border and right-border of the wrong thickness.

(This seems to be most likely to happen if I've activated the border in all of the other cells in the last 2 rows.)

If I adjust and then restore the zoomlevel (e.g. Ctrl+, Ctrl-), it fixes itself -- so it seems to be an invalidation issue of some sort. (Doesn't fix itself on a tab-switch, though.)

Comment 9

[Daniel Holbert [:dholbert]]

I'm definitely not seeing the bad behavior that was described in comment 0, though. (The reporter said "In no case does it turn all the borders of the clicked cell blue" -- but I'm always seeing it turn all the borders of the clicked cell blue. Hooray!)

It looks like what remains is just a minor invalidation/repaint issue with border-thickness (and it sounds like that was the case as of comment 1, too).  So yeah, let's call this WFM -- and I filed bug 1412129 on the remaining issue.  And as Marcia said, there's no need to track any of this for 58.