New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 762065 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

table first cell updating with wrong width

Reported by speedy18...@gmail.com, Sep 5 2017

Issue description

UserAgent: 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:
 
bug_report.png
185 KB View Download
 Issue 762068  has been merged into this issue.
 Issue 762067  has been merged into this issue.
 Issue 762066  has been merged into this issue.

Comment 4 by meade@chromium.org, 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.

minehook.html
803 bytes View Download

Comment 5 by meade@chromium.org, Sep 6 2017

Cc: meade@chromium.org e...@chromium.org r...@opera.com
Labels: Needs-Bisect
Status: Untriaged (was: Unconfirmed)
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?
Thanks, the bug is also displayed when the table element is empty. (Change the nth-child(4) to nth-child(3))
Cc: hdodda@chromium.org
Labels: -Needs-Bisect M-63 Needs-Triage-M60 OS-Linux OS-Mac
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!



Comment 8 by r...@opera.com, Sep 6 2017

Components: -Blink>CSS Blink>Layout
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 .

table.html
259 bytes View Download

Comment 9 by msten...@opera.com, Sep 6 2017

Cc: msten...@opera.com

Comment 10 by r...@opera.com, Sep 6 2017

Attached case with a better pass condition not requiring media queries or resizing.

table.html
249 bytes View Download
Components: -Blink>Layout Blink>Layout>Table
Status: Available (was: Untriaged)
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.
tc.html
372 bytes View Download

Comment 12 Deleted

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]. 
Project Member

Comment 14 by sheriffbot@chromium.org, Sep 7

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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
Status: Available (was: Untriaged)

Sign in to add a comment