Bug 67100 - REGRESSION (r93614): Safari Reader doesn’t repaint correctly when scrolling
Summary: REGRESSION (r93614): Safari Reader doesn’t repaint correctly when scrolling
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P1 Major
Assignee: Julien Chaffraix
URL:
Keywords: HasReduction, InRadar, Regression
: 70402 (view as bug list)
Depends on: 75353
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-28 21:11 PDT by mitz
Modified: 2012-01-10 07:49 PST (History)
5 users (show)

See Also:


Attachments
Possible reduction (2.85 KB, text/html)
2011-12-26 22:59 PST, mitz
no flags Details
Proposed fix: remove optimization that was wrongly kept. (11.64 KB, patch)
2011-12-28 04:41 PST, Julien Chaffraix
no flags Details | Formatted Diff | Diff
Updated fix: Same code change, converted the 2 tests to normal tests with SL baselines. (77.58 KB, patch)
2012-01-09 05:47 PST, Julien Chaffraix
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2011-08-28 21:11:39 PDT
<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
Comment 1 Julien Chaffraix 2011-08-29 10:48:17 PDT
(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?
Comment 2 Julien Chaffraix 2011-09-02 13:40:00 PDT
> 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.
Comment 3 mitz 2011-10-19 14:08:20 PDT
*** Bug 70402 has been marked as a duplicate of this bug. ***
Comment 4 Julien Chaffraix 2011-11-28 15:53:30 PST
FYI bug 71550 solved some regressions related with r93614. Unfortunately it does not seem to have solved Safari Reader's regression.
Comment 5 mitz 2011-12-26 22:59:22 PST
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.
Comment 6 Julien Chaffraix 2011-12-28 02:31:04 PST
Thanks Mitz! I can reproduce the issue now, let me knock out this nasty regression.
Comment 7 Julien Chaffraix 2011-12-28 04:41:20 PST
Created attachment 120651 [details]
Proposed fix: remove optimization that was wrongly kept.
Comment 8 WebKit Review Bot 2011-12-29 06:06:35 PST
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>
Comment 9 WebKit Review Bot 2011-12-29 06:06:42 PST
All reviewed patches have been landed.  Closing bug.
Comment 10 mitz 2011-12-29 09:24:59 PST
Looks like the change was reverted in <http://trac.webkit.org/r103800>.
Comment 11 Julien Chaffraix 2012-01-09 05:21:24 PST
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.
Comment 12 Julien Chaffraix 2012-01-09 05:47:00 PST
Created attachment 121650 [details]
Updated fix: Same code change, converted the 2 tests to normal tests with SL baselines.
Comment 13 WebKit Review Bot 2012-01-10 07:49:03 PST
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>
Comment 14 WebKit Review Bot 2012-01-10 07:49:08 PST
All reviewed patches have been landed.  Closing bug.