Able to reproduce the issue on Mac 10.13.3 using chrome reported version #67.0.3396.99 and latest canary #69.0.3472.3. Issue is specific to OS-mac.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Over to flackr for position sticky triage.

Actually their is still compat issues with firefox and negative top margin... I added to the original testcase a wee bit to see how all 3 browsers behave differently. Primarily by making the header not fully opaque, so you can see how the content alongside the sticky header behaves.

http://next.plnkr.co/edit/QkTDlr9FRKxijejC

I also added a second scroller that has the padding not on the scrolling element, but on a wrapper element inside the scroller. Notice how this padding changes effect firefox compared the chrome/safari. This may be due to the age old https://github.com/w3c/csswg-drafts/issues/129.

To be clear the compat issue is not my primary concern. Yes, there are subtle differences between how the sticky positioned elements are rendered/scrolled in relation to padding/margin. I'd prefer to avoid pinning this ticket to that problem.

My primary concern is that the elements interactable/clickable region becomes inconsistent with where it is actually rendered on screen in Blink. If you view your plunkr in Firefox both the left and right submit buttons' interact regions match their rendered element. n Chrome the left submit button becomes inconsistent while the right button remains consistent.

I can see the issue as well. CC'ing more folks who are more expert in this area for triaging.

The Chrome issue seems to be related in a difference of behavior in out main thread and compositor thread position sticky path.


On my linux box, I can repro the issue if I force the <div class='main'> to be composited [1]. Doing so, puts the sticky element at a different position. Our main thread implementation 
behavior matches the Firefox. See attached screenshots.

More importantly the fact that compositor calculated position is different from main thread, results in incorrect hit-testing as pointed out by the original report.

I am not going to guess wether main offset calculation is correct or not but regardless
we need to ensure out compositor code path computes the same offset as main.




[1] e.g. by adding  'backface-visibility: hidden;'

Deleted: main-sticky.png 148 KB

	main-sticky.png 148 KB View Download

Deleted: compositor-sticky.png 93.8 KB

	compositor-sticky.png 93.8 KB View Download

/cc yigu@ and smcgruer@ who have worked on stick code most recently.

BTW, if you want to see something **fun** use larger negative margins when container is composited.

Seems like this could have been inadvertently *fixed, as the broken behavior I used to see in the test case is now gone.

Right. It was fixed in  issue 841551 .