New issue
Advanced search Search tips

Issue 679772 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner:
Closed: Dec 13
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

IntersectionObserver rootMargin behaves differently on ChromeOS

Project Member Reported by blois@google.com, Jan 10 2017

Issue description

UserAgent: Mozilla/5.0 (X11; CrOS x86_64 8872.73.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.103 Safari/537.36
Platform: 8872.73.0 (Official Build) stable-channel link

Steps to reproduce the problem:
1. http://peteblois.github.io/tmp/intersection_chromeos.html
2. View console output, expect it to not report errors
3. 

What is the expected behavior?
The visual position of an element which results in an IntersectionObserver callback should be consistent.

What went wrong?
The scroll position where IntersectionObserver fires events is substantially off compared to OSX and Linux, it appears that rootMargin behaves differently on ChromeOS.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 55.0.2883.103  Channel: stable
OS Version: 8872.73.0
Flash Version:
 

Comment 1 by e...@chromium.org, Jan 10 2017

Owner: szager@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 2 by szager@chromium.org, Jan 11 2017

I don't understand why you expect the target element to no longer be intersecting after you set container.scrollTop = 101.  Even with the negative top rootMargin of -50px, there will still be 49px (vertically) of the target intersecting.

I'm on a chromeos device, and away from my regular workstation for a while.  Can you provide details about the behavior you're seeing on chromeos vs. other platforms?
 Issue 678381  has been merged into this issue.
Status: WontFix (was: Assigned)
Closing due to lack of feedback.

Sign in to add a comment