Bug 67100 – REGRESSION (r93614): Safari Reader doesn’t repaint correctly when scrolling

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

<rdar://problem/10037421>

Two-finger scrolling in Safari Reader leads to situations where Reader’s scrollbar reaches the end of the track, but the content isn’t scrolled all the way through. Forcing a repaint (for example, by dragging to select text) reveals that the content has scrolled correctly, but just failed to repaint in its final position.

To reproduce:
1. Two-finger scroll to the bottom of an article presented in Safari Reader. It’s best if you don’t use momentum scrolling, just drag all the way.
2. Notice how the bottom of the article is not scrolled all the way up (leaving a wide black margin)
3. Drag to select text, or start scrolling in the opposite direction, or force a repaint

[Julien Chaffraix]

(In reply to comment #0)
> <rdar://problem/10037421>
> 
> Two-finger scrolling in Safari Reader leads to situations where Reader’s scrollbar reaches the end of the track, but the content isn’t scrolled all the way through.

I can sometimes reproduce it using page-up / down for scrolling. Is there a way to look at the Reader JS code to reduce the problem?

[Julien Chaffraix]

> I can sometimes reproduce it using page-up / down for scrolling. Is there a way to look at the Reader JS code to reduce the problem?

I did not find a way to get a reduction and I am now pretty sure the proprietary bits are needed to do that. If someone from Apple could get a reduction, I would happily look into fixing it. In the meantime I don't know if this bug could impact any real web-page.

*** Bug 70402 has been marked as a duplicate of this bug. ***

[Julien Chaffraix]

FYI bug 71550 solved some regressions related with r93614. Unfortunately it does not seem to have solved Safari Reader's regression.

Created attachment 120568 [details]
Possible reduction

Attaching a test case, derived from Reader, which regressed in r67100 and is not fixed yet. Note that it fails whether accelerated compositing is enabled or not.

[Julien Chaffraix]

Thanks Mitz! I can reproduce the issue now, let me knock out this nasty regression.

[Julien Chaffraix]

Created attachment 120651 [details]
Proposed fix: remove optimization that was wrongly kept.

[WebKit Review Bot]

Comment on attachment 120651 [details]
Proposed fix: remove optimization that was wrongly kept.

Clearing flags on attachment: 120651

Committed r103798: <http://trac.webkit.org/changeset/103798>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

Looks like the change was reverted in <http://trac.webkit.org/r103800>.

[Julien Chaffraix]

For the record, the small differences are very platform specific and I don't see a common denominator (apart that they are scrollbars related):

http://build.webkit.org/old-results/Chromium%20Win%20Release%20(Tests)/r103798%20(22347)/fast/layers/scroll-with-transform-layer-diffs.html
http://build.webkit.org/old-results/Chromium%20Mac%20Release%20(Tests)/r103798%20(11346)/fast/layers/scroll-with-transform-layer-diffs.html

The custom scrollbar theme would likely help but I don't think it's enabled everywhere yet so I will just convert the ref-tests to normal tests.

[Julien Chaffraix]

Created attachment 121650 [details]
Updated fix: Same code change, converted the 2 tests to normal tests with SL baselines.

[WebKit Review Bot]

Comment on attachment 121650 [details]
Updated fix: Same code change, converted the 2 tests to normal tests with SL baselines.

Clearing flags on attachment: 121650

Committed r104575: <http://trac.webkit.org/changeset/104575>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.