WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
151224
Remove swipe snapshot before main document load if scroll position is already restored
https://bugs.webkit.org/show_bug.cgi?id=151224
Summary
Remove swipe snapshot before main document load if scroll position is already...
Tim Horton
Reported
Thursday, November 12, 2015 10:24:08 PM UTC
Remove swipe snapshot before main document load if scroll position is already restored
Attachments
Patch
(16.76 KB, patch)
2015-11-12 14:24 PST
,
Tim Horton
no flags
Details
Formatted Diff
Diff
Patch
(19.15 KB, patch)
2015-11-12 14:38 PST
,
Tim Horton
no flags
Details
Formatted Diff
Diff
Patch
(19.78 KB, patch)
2015-11-13 10:19 PST
,
Tim Horton
darin
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Tim Horton
Comment 1
Thursday, November 12, 2015 10:24:50 PM UTC
Created
attachment 265434
[details]
Patch
Tim Horton
Comment 2
Thursday, November 12, 2015 10:38:46 PM UTC
Created
attachment 265436
[details]
Patch
Tim Horton
Comment 3
Friday, November 13, 2015 6:19:16 PM UTC
Created
attachment 265484
[details]
Patch
Darin Adler
Comment 4
Sunday, November 15, 2015 2:50:58 AM UTC
Comment on
attachment 265484
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=265484&action=review
> Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:207 > + WTFLogAlways("requestScrollPositionUpdate %d", scrollPosition.y());
Did you mean to leave this in?
> Source/WebKit2/UIProcess/ViewGestureController.cpp:126 > +#if PLATFORM(MAC) > + // On Mac, we check if the scroll position restoration succeeded by comparing the > + // requested and actual scroll position. It's possible that we will never succeed in restoring > + // the exact scroll position we wanted, in the case of a dynamic page, but we know that by > + // main frame load time that we've gotten as close as we're going to get, so stop waiting. > + // We don't want to do this on iOS because scroll position restoration is baked into the transaction. > + m_snapshotRemovalTracker.cancelOutstandingEvent(SnapshotRemovalTracker::ScrollPositionRestoration); > +#endif
This mentions Mac and iOS; not sure if other platforms would be more like Mac or more like iOS.
> Source/WebKit2/UIProcess/ios/PageClientImplIOS.mm:758 > +{ > + > +}
I’d omit the blank line.
Tim Horton
Comment 5
Sunday, November 15, 2015 7:20:52 AM UTC
(In reply to
comment #4
)
> Comment on
attachment 265484
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=265484&action=review
> > > Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:207 > > + WTFLogAlways("requestScrollPositionUpdate %d", scrollPosition.y()); > > Did you mean to leave this in?
Definitely not.
> > Source/WebKit2/UIProcess/ViewGestureController.cpp:126 > > +#if PLATFORM(MAC) > > + // On Mac, we check if the scroll position restoration succeeded by comparing the > > + // requested and actual scroll position. It's possible that we will never succeed in restoring > > + // the exact scroll position we wanted, in the case of a dynamic page, but we know that by > > + // main frame load time that we've gotten as close as we're going to get, so stop waiting. > > + // We don't want to do this on iOS because scroll position restoration is baked into the transaction. > > + m_snapshotRemovalTracker.cancelOutstandingEvent(SnapshotRemovalTracker::ScrollPositionRestoration); > > +#endif > > This mentions Mac and iOS; not sure if other platforms would be more like > Mac or more like iOS.
You raise a good point. Really, this should be "uses UI-side compositing/transactional scrolling/something", and we'd want the "iOS" behavior if you were using UI-side compositing on Mac. We don't have a fantastic way to tell right now, but we should. I'll come up with something.
> > Source/WebKit2/UIProcess/ios/PageClientImplIOS.mm:758 > > +{ > > + > > +} > > I’d omit the blank line.
Tim Horton
Comment 6
Tuesday, December 1, 2015 7:36:53 PM UTC
(In reply to
comment #5
)
> (In reply to
comment #4
) > > Comment on
attachment 265484
[details]
> > Patch > > > > View in context: > >
https://bugs.webkit.org/attachment.cgi?id=265484&action=review
> > > > > Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:207 > > > + WTFLogAlways("requestScrollPositionUpdate %d", scrollPosition.y()); > > > > Did you mean to leave this in? > > Definitely not. > > > > Source/WebKit2/UIProcess/ViewGestureController.cpp:126 > > > +#if PLATFORM(MAC) > > > + // On Mac, we check if the scroll position restoration succeeded by comparing the > > > + // requested and actual scroll position. It's possible that we will never succeed in restoring > > > + // the exact scroll position we wanted, in the case of a dynamic page, but we know that by > > > + // main frame load time that we've gotten as close as we're going to get, so stop waiting. > > > + // We don't want to do this on iOS because scroll position restoration is baked into the transaction. > > > + m_snapshotRemovalTracker.cancelOutstandingEvent(SnapshotRemovalTracker::ScrollPositionRestoration); > > > +#endif > > > > This mentions Mac and iOS; not sure if other platforms would be more like > > Mac or more like iOS. > > You raise a good point. Really, this should be "uses UI-side > compositing/transactional scrolling/something", and we'd want the "iOS" > behavior if you were using UI-side compositing on Mac. We don't have a > fantastic way to tell right now, but we should. I'll come up with something.
... but in another patch, because it is going to be a sizable project to get ViewGestureController to work correctly based on DrawingArea implementation instead of platform ifdefs.
> > > Source/WebKit2/UIProcess/ios/PageClientImplIOS.mm:758 > > > +{ > > > + > > > +} > > > > I’d omit the blank line.
Tim Horton
Comment 7
Tuesday, December 1, 2015 7:57:35 PM UTC
http://trac.webkit.org/changeset/192898
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug