New issue
Advanced search Search tips

Issue 739108 link

Starred by 1 user

Issue metadata

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



Sign in to add a comment

CSS not rerendering correctly after class change

Reported by m...@issuu.com, Jul 4 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0

Steps to reproduce the problem:
1. Go to https://issuu.com/localwolves/docs/winter2017?large-view-button=hest
2. See the read more on the right
3. Click the "large view" button
4. See the read more move down (expected) but the covers being all scaled up

What is the expected behavior?
The covers should have the proper size. This is correct in Firefox and can be forced in Chrome when either changing the width of the window or changing the CSS of `div.ExploreShelf__cover--1ksly` by disabling and reenabling the `margin-button` property thus forcing the browser to recalculate sizes.

What went wrong?
If you reload the page, it stays in the large view and serves the bottom read more which is shown in the correct size. It seems that the class triggering display of said div does not force the recalculation of the size of the div upon display, thus the values there do not make any sense and lead to incorrect rendering.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 59.0.3071.115 (Official Build) (64-bit)  Channel: stable
OS Version: OS X 10.12
Flash Version:
 
Screen Shot 2017-07-04 at 11.16.32.png
1.1 MB View Download
Screen Shot 2017-07-04 at 11.17.14.png
712 KB View Download
Labels: Needs-Bisect OS-Chrome
Status: Untriaged (was: Unconfirmed)
Reproduced this in M58 on Chrome OS, but not M61 on Linux.

Note that the "large view" button mentioned in step 2 is the second button from the right in the dark area.

Comment 2 by m...@issuu.com, Jul 5 2017

Sorry, I should have mentioned that. I just tried with Version 61.0.3149.0 (Official Build) canary (64-bit) on MacOS and that seems to work fine.

Labels: OS-Windows
Testing on Windows 10 - I could repro in Chrome 59 (stable) and also Chrome 61.0.3148.0 (Official Build) canary (32-bit) (cohort: 32-Bit). 

Tweaked Repro Steps:
 - visit https://issuu.com/localwolves/docs/winter2017?large-view-button=hest
 - if the page is already in 'large view' mode, press the same button to go back to 'small view' mode, and make sure to reload the page
 - press 'large view' to see the problem


Labels: -Needs-Bisect M-61 OS-Linux
Tested on Chrome Stable #59.0.3071.115 and Canary #61.0.3148.0 on Windows 10, Mac 10.12.5 and Ubuntu 14.04 and issue is reproducible. 
 
This is a non-regression issue and able to reproduce from M-45 #45.0.2454.101. 
 
Thanks.

Components: -Blink>CSS Blink>Layout
Before and after clicking the "large view" button, the covers have style:
max-height: 340px;
max-width: 100%;
width: 100%;

What does the "large view" button do? A simpler test case would be welcome.

Comment 6 by m...@issuu.com, Jul 7 2017

The large view button does hide the right "read more" sidebar and display the bottom "read more" sidebar. This is done using CSS `display` properties. If it is done by just not adding the elements to the DOM it works just fine.

Unfortunately it is a quite complex setup with React so it is pretty hard to produce a useful reproducer, sorry.

Comment 7 by e...@chromium.org, Jul 10 2017

Labels: Needs-Reduction

Comment 8 by e...@chromium.org, Jul 14 2017

Owner: cbiesin...@chromium.org
Status: Assigned (was: Untriaged)
Would you mind taking a look at this one cbiesinger?

Sign in to add a comment