Bug 48017 - Incorrect scrolling behavior with the compositor and position: fixed elements
Summary: Incorrect scrolling behavior with the compositor and position: fixed elements
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2010-10-20 15:49 PDT by Mihai Parparita
Modified: 2015-07-22 17:45 PDT (History)
5 users (show)

See Also:

Attachments
Test case (486 bytes, text/html)
2010-10-20 15:49 PDT, Mihai Parparita 		no flags Details
Screenshot (292.77 KB, image/png)
2010-10-20 16:12 PDT, Mihai Parparita 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mihai Parparita 2010-10-20 15:49:17 PDT 
Created attachment 71350 [details]
Test case

Load the attached test case. Scroll the page.

Expected behavior: nothing scrolls, since the content is an position: fixed element.

Actual behavior: The gray rectangle stays put, but the text around it scrolls.

This is triggered by -webkit-transform: translateZ(0px) property on the gray element, hence the suspicion that the compositor is involved.

This is a reduction of http://crbug.com/58982, which is a bug that affects twitter.com. This is not a recent WebKit regression (happens with Safari 5.0.2), but only started to happen with Chrome 8 (where I believe we enabled the compositor for the first time).
Comment 1 Simon Fraser (smfr) 2010-10-20 16:03:26 PDT 
<rdar://problem/8576233>
Comment 2 Simon Fraser (smfr) 2010-10-20 16:04:28 PDT 
Can you give the Twitter URL that shows this?
Comment 3 Mihai Parparita 2010-10-20 16:11:39 PDT 
Twitter doesn't seem to have permalinks for expanded pages, but to reproduce:

1. Set the user agent to "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.41 Safari/534.7" (otherwise the map data doesn't load at all, presumably another bug on Twitter's side)
1. Load http://twitter.com/#!/anildash (while signed in)
2. Find a tweet with a location (any that say "from Gramercy Park") and click on it
3. Scroll the whole page and/or the right-side preview area.
Comment 4 Mihai Parparita 2010-10-20 16:12:01 PDT 
Created attachment 71352 [details]
Screenshot
Comment 5 Simon Fraser (smfr) 2010-12-08 21:59:55 PST 
I think the issue is that we normally repaint the entire view after scrolling if there are fixed position elements. However, with compositing layers, we don't. This may also affect fixed backgrounds too.
Comment 6 Simon Fraser (smfr) 2010-12-08 22:00:57 PST 
The easy fix is to do more repainting. A smarter fix would be to make compositing layers for position:fixed elements (if there is other compositing on the page), so that we can scroll without painting.
Comment 7 Julien Chaffraix 2011-12-01 09:38:21 PST 
> A smarter fix would be to make compositing layers for position:fixed elements (if there is other compositing on the page), so that we can scroll without painting.

For the record, bug 69796 landed which enables composited layers for position: fixed elements. However the bug is still present (tested on ToT Chromium).
Comment 8 lars.sonchocky-helldorf 2012-04-13 15:00:02 PDT 
I've reported https://bugs.webkit.org/show_bug.cgi?id=83948 since to me this appears a different issue. If this is not the case please close 83948 as duplicate.
Comment 9 Simon Fraser (smfr) 2015-07-22 17:45:02 PDT 
This seems to work correctly now.