Bug 108625

Summary: Scrollbars misplaced with accelerated compositing for overflow scroll
Product: WebKit Reporter: Allan Sandfeld Jensen <allan.jensen>
Component: Layout and RenderingAssignee: Allan Sandfeld Jensen <allan.jensen>
Status: RESOLVED FIXED    
Severity: Normal CC: buildbot, dglazkov, eric, jamesr, ojan.autocc, rniwa, simon.fraser, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Description Allan Sandfeld Jensen 2013-02-01 05:49:18 PST
If the setting AcceleratedCompositingForOverflowScroll is enabled, the scrolling content is automatically given its own layer, but the scrollbars are rendered on the content layer instead of on their own layer. This means the scrollbars can be scrolled out of the visible view. Chromium has a platform ifdef to fix that, but it should be fixed generally.
Comment 1 Allan Sandfeld Jensen 2013-02-01 05:52:35 PST
Created attachment 186026 [details]
Patch
Comment 2 Build Bot 2013-02-01 06:34:43 PST
Comment on attachment 186026 [details]
Patch

Attachment 186026 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/16299689

New failing tests:
compositing/overflow/composited-scrolling-creates-a-stacking-container.html
Comment 3 Build Bot 2013-02-01 07:40:18 PST
Comment on attachment 186026 [details]
Patch

Attachment 186026 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://queues.webkit.org/results/16298683

New failing tests:
compositing/overflow/composited-scrolling-creates-a-stacking-container.html
Comment 4 Allan Sandfeld Jensen 2013-02-01 08:22:27 PST
Created attachment 186052 [details]
Patch

Update the result for the one test overriding accelerated compositing for overflow scroll on all ports.
Comment 5 WebKit Review Bot 2013-02-01 18:27:09 PST
Comment on attachment 186052 [details]
Patch

Attachment 186052 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/16334419

New failing tests:
fast/forms/datalist/update-range-with-datalist.html
compositing/scrollbar-painting.html
fast/layers/no-clipping-overflow-hidden-hardware-acceleration.html
fast/layers/no-clipping-overflow-hidden-added-after-transform.html
compositing/geometry/limit-layer-bounds-transformed-overflow.html
compositing/overflow/content-gains-scrollbars.html
fast/loader/javascript-url-in-object.html
compositing/overflow/overflow-scrollbar-layers.html
fast/loader/text-document-wrapping.html
compositing/iframes/resizer.html
fast/layers/no-clipping-overflow-hidden-added-after-transition.html
compositing/overflow/resize-painting.html
compositing/overflow/clip-content-under-overflow-controls.html
compositing/overflow/repaint-after-losing-scrollbars.html
compositing/layer-creation/overflow-scroll-overlap.html
Comment 6 Allan Sandfeld Jensen 2013-02-05 02:39:54 PST
(In reply to comment #5)
> (From update of attachment 186052 [details])
> Attachment 186052 [details] did not pass chromium-ews (chromium-xvfb):
> Output: http://queues.webkit.org/results/16334419
> 
> New failing tests:
> fast/forms/datalist/update-range-with-datalist.html
> compositing/scrollbar-painting.html
> fast/layers/no-clipping-overflow-hidden-hardware-acceleration.html
> fast/layers/no-clipping-overflow-hidden-added-after-transform.html
> compositing/geometry/limit-layer-bounds-transformed-overflow.html
> compositing/overflow/content-gains-scrollbars.html
> fast/loader/javascript-url-in-object.html
> compositing/overflow/overflow-scrollbar-layers.html
> fast/loader/text-document-wrapping.html
> compositing/iframes/resizer.html
> fast/layers/no-clipping-overflow-hidden-added-after-transition.html
> compositing/overflow/resize-painting.html
> compositing/overflow/clip-content-under-overflow-controls.html
> compositing/overflow/repaint-after-losing-scrollbars.html
> compositing/layer-creation/overflow-scroll-overlap.html

I am tempted to preserving the chromium quirk for now, so chromium always have layers for the scrollbars, accelerated overflow scroll or not. Though I suspect fixing it would reduce the baseline differences.
Comment 7 Allan Sandfeld Jensen 2013-02-05 05:32:37 PST
Created attachment 186607 [details]
Patch

Let Chromium stay unchanged so their baselines still match.
Comment 8 James Robinson 2013-02-05 09:02:19 PST
(In reply to comment #6)
> (In reply to comment #5)
> > (From update of attachment 186052 [details] [details])
> > Attachment 186052 [details] [details] did not pass chromium-ews (chromium-xvfb):
> > Output: http://queues.webkit.org/results/16334419
> > 
> > New failing tests:
> > fast/forms/datalist/update-range-with-datalist.html
> > compositing/scrollbar-painting.html
> > fast/layers/no-clipping-overflow-hidden-hardware-acceleration.html
> > fast/layers/no-clipping-overflow-hidden-added-after-transform.html
> > compositing/geometry/limit-layer-bounds-transformed-overflow.html
> > compositing/overflow/content-gains-scrollbars.html
> > fast/loader/javascript-url-in-object.html
> > compositing/overflow/overflow-scrollbar-layers.html
> > fast/loader/text-document-wrapping.html
> > compositing/iframes/resizer.html
> > fast/layers/no-clipping-overflow-hidden-added-after-transition.html
> > compositing/overflow/resize-painting.html
> > compositing/overflow/clip-content-under-overflow-controls.html
> > compositing/overflow/repaint-after-losing-scrollbars.html
> > compositing/layer-creation/overflow-scroll-overlap.html
> 
> I am tempted to preserving the chromium quirk for now, so chromium always have layers for the scrollbars, accelerated overflow scroll or not. Though I suspect fixing it would reduce the baseline differences.

It's not really a "quirk" so much as an intentional performance tradeoff.
Comment 9 Allan Sandfeld Jensen 2013-02-06 02:48:07 PST
(In reply to comment #8)
> 
> It's not really a "quirk" so much as an intentional performance tradeoff.

The quirk is that it is always enabled rather than only when accelerated compositing of overflow scroll is enabled. You probably always have it enabled in Chrome, but in the test framework it can be disabled which leads to different results.
Comment 10 James Robinson 2013-02-06 11:22:30 PST
(In reply to comment #9)
> (In reply to comment #8)
> > 
> > It's not really a "quirk" so much as an intentional performance tradeoff.
> 
> The quirk is that it is always enabled

Which is the behavior we want.

> rather than only when accelerated compositing of overflow scroll is enabled.

That would not be the behavior we want.

> You probably always have it enabled in Chrome, but in the test framework it can be disabled which leads to different results.
Comment 11 Allan Sandfeld Jensen 2013-02-07 02:42:08 PST
Simon, can I assume your review still applies to the updated patch? Chromium definitely prefers to stay unchanged.
Comment 12 WebKit Review Bot 2013-02-07 09:31:07 PST
Comment on attachment 186607 [details]
Patch

Clearing flags on attachment: 186607

Committed r142140: <http://trac.webkit.org/changeset/142140>
Comment 13 WebKit Review Bot 2013-02-07 09:31:11 PST
All reviewed patches have been landed.  Closing bug.