Bug 192877 - user scrollable overflow causes behavior "as-if-positioned" lifting itself higher in paint order than if not overflowing
Summary: user scrollable overflow causes behavior "as-if-positioned" lifting itself hi...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-12-19 14:05 PST by jonjohnjohnson
Modified: 2018-12-20 16:23 PST (History)
4 users (show)

See Also:


Attachments
animating scrollable content to expose paint order bug (937 bytes, text/html)
2018-12-19 14:05 PST, jonjohnjohnson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description jonjohnjohnson 2018-12-19 14:05:23 PST
Created attachment 357723 [details]
animating scrollable content to expose paint order bug

Can't seem to find a webkit bug tracking this, though it is seemingly known among vendor developers (https://github.com/w3c/csswg-drafts/issues/2717#issuecomment-395911418)

1. Open the attached case.
2. Watch overflow:auto box that has green content grow and shrink, creating and removing user scrollable content every 2 seconds.
3. See that when it overflows, it behaves as-if-positioned painted higher and lower in order than the red block (which also is always lifted higher because of overflow).

Compat
Firefox doesn't let "user scrollable" overflow affect paint order, red block is always behind green in test case.
Blink has same/similar issue, but is working on fix??? https://bugs.chromium.org/p/chromium/issues/detail?id=370604#c_ts1545253494


*I say user scrollable, because overflow:hidden doesn't create compositing order issue
Comment 1 Radar WebKit Bug Importer 2018-12-20 16:23:21 PST
<rdar://problem/46887177>