New issue
Advanced search Search tips

Issue 836180 link

Starred by 1 user
Status: Duplicate
Merged: issue 823433
Owner:
chrishtr@chromium.org
Closed: Apr 2018
Cc:
szager@chromium.org
nyerramilli@chromium.org
rbasuvula@chromium.org
chrishtr@chromium.org
wfh@chromium.org
creis@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression:Contents on price.com extension overlay disappear when page is scrolled

Reported by vineetha...@etouch.net, Apr 24 2018 
Chrome Version: 67.0.3396.18 (Official Build) 399b73768e46f9219d4868a2ad1ccb517da5347d-refs/branch-heads/3396@{#251}(32/64 bit)
OS: Windows(7,8,8.1,10), Linux(14.04 LTS), Mac(10.12.6, 10.13.1, 10.13.5)

URL: https://chrome.google.com/webstore/search/price.com?hl=en-GB

What steps will reproduce the problem?
(1) Launch Chrome, navigate to above URL and add price.com extension.
(2) Navigate to 'www.price.com' and click on the price.com extension icon near the omnibox to open the overlay.
(3) Now scroll the page and observe.

Actual Result: Contents on price.com extension overlay disappear when page is scrolled.
Expected Result: Contents on price.com extension overlay should be seen properly when page is scrolled.

This is regression issue broken in ‘M-67’ and providing the bisect using per-revision bisect,
Good build: 67.0.3368.0(Revision: 542341)
Bad build: 67.0.3369.0(Revision: 542817)

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

CHANGE-LOG 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/5a61c77321fa4fd5305c470f766b8bc0ab201132..b2c9e2623c8b6a1abdd28acb9e682988c826938c

Suspect: https://chromium.googlesource.com/chromium/src/+/b2c9e2623c8b6a1abdd28acb9e682988c826938c

@kenrb: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thank You!
ActualResult.mov
6.8 MB View Download
ExpectedVideo.mov
6.2 MB View Download

Comment 1 by kenrb@chromium.org, Apr 24 2018

Cc: chrishtr@chromium.org szager@chromium.org
Components: Internals>Sandbox>SiteIsolation
Stefan or Chris can you help me understand what is happening here?

This appears to be a problem with the intersection observer calculation when using LayoutObject::MapToVisualRectInAncestorSpace(). The bug is manifesting because we are now using the viewport intersection rect to clip the area that the OOPIF compositor rasters.

Specifically, this is an OOPIF within a div that has position:fixed. When we scroll the main frame, MapToVisualRectInAncestorSpace() is accounting for the main frame's scroll offset. This is a problem because the div does not move.

I haven't been able to find anywhere in the relevant layout calculations where it is supposed to take CSS position into account, but I feel like it should. Is this a bug in layout code?

Comment 2 by vineetha...@etouch.net, Apr 26 2018 

Just to update, the above issue is also seen for the extension 'Evernote Web Clipper',
Chrome webstore url for extension : https://chrome.google.com/webstore/search/Evernote%20Web%20Clipper?hl=en-GB

Comment 3 by creis@chromium.org, Apr 26 2018

Components: Blink>Layout
szager@ or chrishtr@: Any thoughts on Ken's layout questions in comment 1?  He's OOO at the moment, but we're hoping to get this fixed quickly when he gets back.  My understanding is that r554097 in  issue 823433  won't fix this, despite both that bug and this one being caused by the same CL (r542376).

Comment 4 by chrishtr@chromium.org, Apr 26 2018

Owner: chrishtr@chromium.org
MapToVisualRectInAncestorSpace does have code to take into accout fixed position.

I'll look.

Comment 5 by chrishtr@chromium.org, Apr 26 2018

Mergedinto: 823433
Status: Duplicate (was: Assigned)
I confirmed that this was fixed by https://chromium-review.googlesource.com/c/chromium/src/+/1005993.

Comment 6 by creis@chromium.org, Apr 27 2018 

Comment 5: Agreed!  Thanks for noticing that, and I can confirm it in today's 68.0.3410.0 Canary.  Seems to be working now.  We're discussing a merge to M67 on  issue 823433 .
►

Sign in to add a comment