New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 132839 link

Starred by 7 users

Issue metadata

Status: Fixed
Closed: Jun 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Scrollbar rendering bug

Reported by, Jun 14 2012

Issue description

Chrome Version       : 19.0.1084.56
OS Version: OS X 10.7.4
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5:OK
  Firefox 4.x: OK
     IE 7/8/9:

What steps will reproduce the problem?
1. Create a scrollable div
2. Put another scrollable div inside of it with css position:relative
3. Put a canvas inside the inner div and render something on it
4. Scroll the outermost div until the inner scrolling div is going off screen (out of sight)

What is the expected result?
The scrollbars of the inner div stay with the div and are scrolled out of sight.

What happens instead?
The scrollbars move until they reach the top (or left for horizontal scrolling) of the outermost scrolling div. They then stay where they are while the rest of the scrolling div and it's content move out of sight.

Please provide any additional information below. Attach a screenshot if


The canvas must have something rendered on it for the bug to occur, and the bug will not occur if the canvas is too small (don't know what the size threshold is).

Attached is a simple html file that will demonstrate the issue. It is also a bug in Chrome on Windows.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5

996 bytes View Download
Labels: OS-Windows
If the size threshold is "works at 256x256 / fails at 257x257", then it's a problem with hardware-accelerated canvas; the example canvas appears to be big enough that it's getting hardware accelerated. This could also be tested by passing 
"--disable-accelerated-2d-canvas" on the command line.

If the note in the original bug report that it's on Mac and on Windows means that it explicitly doesn't occur on Linux, that's another indication that it's from hardware accelerated canvas 2d, since we normally turn that feature off on all Linux machines.
Another note: turning off position: relative on the 'inner-scrollable' div fixes the scrolling issue.
looks like this may be the same as ?   but I haven't looked carefully at either of these issues yet so I don't feel comfortable marking them as duplicates myself.
sorry for the noise. I think its different.

Comment 5 by, Jun 14 2012

I didn't ever test in in Linux, just Windows and OS X. And yes, it goes away without the position: relative. position: absolute has the same affect. The bug was discovered with a series of nested absolutely positioned divs. I just tried to simplify the problem down to a basic form.

Comment 6 by, Jun 14 2012

Confirmed that the size threshold is 256x256. No bug when canvas is that size. 257x257 created the bug. Must be hardware-accelerated issue.

Comment 7 by, Jun 14 2012

glancing at the code looks like the canvas is acting as a compositor trigger when accelerated canvas is turned on, as has been noted -> looking at enne for recent scrollbar work?

Comment 9 by, Jun 14 2012

As per the bug report, this is happening in m19, so unlikely related to anything recent.
Labels: -Area-Undefined Area-WebKit Feature-GPU-Compositing

Comment 12 by, Jun 19 2012

As a workaround in the short term, you can add a -webkit-transform:translateZ(0) to the inner-scrollable or the body itself.

It looks like the problem manifests when the inner-scrollable's scrollbars get their own composited layers (due to the canvas accelerated compositing trigger) and the inner-scrollable doesn't get its own backing.

Comment 13 by, Jun 19 2012

Labels: -OS-Mac -OS-Windows OS-All
Status: Assigned

Comment 14 by, Jun 19 2012

Labels: WebKit-ID-89486
Project Member

Comment 15 by, Jun 19 2012

Labels: -WebKit-ID-89486 WebKit-ID-89486-NEW
Project Member

Comment 16 by, Jun 19 2012

Labels: -WebKit-ID-89486-NEW WebKit-ID-89486-RESOLVED WebKit-Rev-120750

Comment 17 by, Jun 19 2012

Labels: Mstone-21
Status: Fixed

Comment 18 by, Jun 20 2012

Labels: Merge-Requested
kareng: this was breaking an I/O demo and is low risk.

Comment 19 by, Jun 20 2012

can we wait till it hits canary tomrorow?

Comment 20 by, Jun 20 2012

Sure, no problem.

Comment 21 by, Jun 20 2012

Labels: -Merge-Requested Merge-Approved

Comment 22 by, Jun 20 2012

Labels: -Merge-Approved Merge-Merged
Merged to m21 in

The change is currently in Chrome canary and will be in the next dev channel build.
Project Member

Comment 23 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 24 by, Mar 10 2013

Labels: -Area-WebKit -Feature-GPU-Compositing -Mstone-21 Cr-Content Cr-Internals-GPU-Compositing M-21
Project Member

Comment 25 by, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 26 by, Apr 5 2013

Labels: -Cr-Internals-GPU-Compositing Cr-Internals-Compositing
Project Member

Comment 27 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Sign in to add a comment