table first cell updating with wrong width
Reported by
speedy18...@gmail.com,
Sep 5 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Steps to reproduce the problem: 1. Open minehook.com/checkout 2. Login with VoxelBoxStudios Account 3. Make the Browser window smaller (300px) and bigger (1200px) What is the expected behavior? What went wrong? The first cell of the table has the wrong width. I think this is a render bug. In the Mozilla Firefox Browser, the bug does not exists. Did this work before? No Does this work in other browsers? Yes Chrome version: 60.0.3112.113 Channel: stable OS Version: 10.0 Flash Version:
,
Sep 5 2017
Issue 762067 has been merged into this issue.
,
Sep 5 2017
Issue 762066 has been merged into this issue.
,
Sep 6 2017
The behaviour looks like the "float: left" on "#product td:nth-child(4)" is not being removed when the window is being made big again. I reduced the website to a small testcase. It's available at https://jsfiddle.net/ca81hzs3/, but it's hard to see (you have to make the window really big before you run it, then make it smaller, and then bigger again). I've also attached the html file, since that is easier to see.
,
Sep 6 2017
I'm requesting a bisect to check if this is a regression. Steps to repro: 1. Open above minehook.html in a large window (observe the bullet list is to the right of the other text) 2. Make the window smaller until the bullet list is below the other text 3. Make the window big again. Observe that the bullet list remains underneath the other text. rune@ and eae@, do you think this is an issue with media queries, invalidation, or layout?
,
Sep 6 2017
Thanks, the bug is also displayed when the table element is empty. (Change the nth-child(4) to nth-child(3))
,
Sep 6 2017
Able to reproduce the issue on windows 7 , Mac OS 10.126 and ubuntu 14.04 using chrome m60 #60.0.3112.113 and M63 #63.0.3206.0 with the steps mentioned in comment #5. This issue is seen from M50 and is a Non-regression issue. Thanks!
,
Sep 6 2017
See attached table.html: I've simplified a bit. The media query is re-evaluated as can be seen by the pink background changing correctly on resize. Most likely a layout issue. I suspect this is related to issue 732834 .
,
Sep 6 2017
,
Sep 6 2017
Attached case with a better pass condition not requiring media queries or resizing.
,
Sep 6 2017
I guess the problem is that we're quite bad at merging anonymous table rows, and that we before the script have:
<anon_row>
<cell></cell>
</anon_row>
<div id="anon_row_splitter"></div>
<anon_row>
<cell></cell>
</anon_row>
After the script, which removes the block between the cells:
<anon_row>
<cell></cell>
</anon_row>
<anon_row>
<cell></cell>
</anon_row>
At this point the two anonymous rows should have been merged into one, so that the two cells become layout siblings, but last time I checked, we didn't support merging of anonymous rows.
,
Sep 7 2017
Tried with the attached files table.html and tc.html. Able to reproduce on reported version 60.0.3112.113 and on latest canary 63.0.3208.0 with the mentioned steps on Ubuntu 14.04, windows 7, Mac 10.12.6 This seems to be a Non-Regression issue seen from M-50[50.0.2624.0].
,
Sep 7
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 7
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by phistuck@chromium.org
, Sep 5 2017