We were able to reproduce on Chrome 62 on a Mac.

Hey Chrome team, wondering if we have a ETA for when this might get fixed.
This is causing a prod breakage on Google Photos when using Chrome 62, would be great if we can fix soon before Chrome 62 is rolled out to more users.

This issue is also giving production issue for BlueConic, see https://support.blueconic.com/hc/en-us/articles/115005492269-Chrome-62-issue-causes-empty-navigation-pages. 

Able to reproduce the issue on windows 10, ubuntu 14.04 and Mac OS 10.12.6 using chrome M62 #62.0.3202.75 and is fixed in latest bet , dev and canary channels.

Using the per-revision bisect providing the reverse bisect results,
Good build: 63.0.3226.0 (Revision: 504841).
Bad build: 63.0.3225.0 (Revision: 504540).


You are probably looking for a change made after 504560 (known good), but no later than 504561 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

  https://chromium.googlesource.com/chromium/src/+log/a9ba55c8571ab0d2624c83d413ccc7215a185f51..9f0c480da9cb188c82e16e6c6751875a60a114cf

Review URL : https://chromium.googlesource.com/chromium/src/+/9f0c480da9cb188c82e16e6c6751875a60a114cf

From the CL above, assigning the issue to the concern owner 

@Rune Lillesveen- Could you please merge the fix to M62 .

Note : Assigning it to the  reviewers as the owner is not available in the list.

Thanks!

I only reverted the first iteration of this CL (which is a reland), I have no idea what's going on. Assigning to the actual reviewer of that CL.

FYI we're introducing a temporary workaround on Google Photos side until this is resolved, this should land on prod today. The workaround consists of applying 'position: fixed' and removing it on the next frame to trigger a repaint/reflow when you land on the shared album.

hdodda@chromium.org,

Can you perform a bisect looking at the change between 63 and 64 as we reverted the CL in question in 64? Just to make sure that I have a correct understanding of the bug. 

@je, and others in need of a fast workaround, a global `*{transition: visibility 0.01s}` in CSS should do the trick and avoid a lot of code refactoring.

THis is fixed on M63

Can we get an explanation on why this is suddenly marked as 'WonFix' without explanation when this was previously noted as fixed for the M63 release?  We were relying on a fix for this being rolled out.

Sorry I should have been clearer there, 
The bug was marked as Fixed since the issue didn't repro on 63. However since no fix was landed that was the correct status to mark the bug as.

The test case in the original filing shouldn't repro in 63 (which should be hitting stable soon.)

I've been waiting for a fix with the release of 63, as one of my sites suffers the same problem. 63.0.3239.84 did not fix the problem, and it is definitely still being reproduced.

I confirm. We have same problems on 63. The bug didn't fixed yet

Could you please file a bug again with a test case? Since the original issue is not reproducable a new test case will help us track it down. 

New issue raised 793192
https://bugs.chromium.org/p/chromium/issues/detail?id=793192