Intersection Oberserver has troubles with sub-pixel by overflow hidden
Reported by
markuskr...@gmail.com,
Apr 16 2018
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3394.0 Safari/537.36 Steps to reproduce the problem: 1. have an element A with a overflow hidden (in my test case it had also a width of 1000px) 2. have an element B inside of element A with an calculated height/width (in my case it was padding-bottom with 56.25%) 4. the computedStyle for height should have a sub-pixel 3. observe element B. What is the expected behavior? when the element B is fully visible on the screen the Intersection Entry should have an intersectionRation > 0.95 What went wrong? The Entry for 100% visibility was never triggered Did this work before? No Does this work in other browsers? N/A Chrome version: 67.0.3394.0 Channel: stable OS Version: OS X 10.13.4 Flash Version: I checked this issue in older Chrome versions and it seems to be broken since version 51 where the intersection Observer was implemented. https://www.tz.de/sport/fc-bayern/hans-joachim-watzke-meisterserie-fc-bayern-wird-enden-9763603.html?glomex-sticky=true on this page it should be also testable. The videos should be sticky when they play and scroll down under the "placeholder" when the placeholder is fully visible it should unstick again.
,
Apr 16 2018
,
Apr 16 2018
,
Apr 17 2018
markuskramm@ Thanks for the issue. Tested this issue on Mac OS 10.13.3 and Ubuntu 14.04 on the reported version 67.0.3394.0 and the latest Canary 68.0.3397.0 by following the below steps. 1. Launched Chrome and navigated to the above given URL. 2. played the video and scrolled through the page and couldn't observe any issues. Attached is the screen cast for reference. Request you to check and confirm if anything is missed from our end in triaging the issue. Also request you to provide a screen cast/screen shot of the expected behavior which will help in further triaging of the issue. Thanks..
,
Apr 17 2018
sorry, maybe my explanation wasn't good enough. The Problem is by scrolling up again where the "sticky" should close again. You have the "wrong" behaviour also in the screen cast. it should close the sticky when 100% is visible again (0:16). But it triggers first when the observed element gets out of the screen on the bottom (0:18). The Problem cause by getting just an intersection ratio which is close to ~0.91 and never to ~1 and of course having fulfilled the repro steps. When it's not clear enough on this page, i can create a separate test page an reduce everything to the minimum we need to reproduce the issue.
,
Apr 17 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 17 2018
here is a html-file, which is reduced to the minimum setup for the issue. You can see in the console, that we will never reach the 100% visibility. Tested it also in MS Edge 16 and Firefox 59 where it was working as intended.
,
Apr 19 2018
Able to reproduce this issue on reported version 67.0.3394.0 , on latest stable 66.0.3359.117 and on latest canary 68.0.3399.0 using Windows 10, Mac 10.13.3 and Ubuntu 14.04. This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged.
,
Apr 19 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by erikc...@chromium.org
, Apr 16 2018