Bug 167484 - Fixed elements should not rubber-band in WK2, nor remain at negative offsets
Summary: Fixed elements should not rubber-band in WK2, nor remain at negative offsets
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-01-26 19:54 PST by Simon Fraser (smfr)
Modified: 2017-01-30 11:48 PST (History)
9 users (show)

See Also:

Attachments
Patch for EWS (13.52 KB, patch)
2017-01-26 20:01 PST, Simon Fraser (smfr) 		no flags Details | Formatted Diff | Diff
Patch (37.41 KB, patch)
2017-01-27 20:36 PST, Simon Fraser (smfr) 		no flags Details | Formatted Diff | Diff
Patch (37.14 KB, patch)
2017-01-27 20:43 PST, Simon Fraser (smfr) 		dino: review+
buildbot: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews121 for ios-simulator-wk2 (842.22 KB, application/zip)
2017-01-27 22:01 PST, Build Bot 		no flags Details
Show Obsolete (2) 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 Simon Fraser (smfr) 2017-01-26 19:54:27 PST 
Fixed elements should not rubber-band in WK2, nor remain at negative offsets
Comment 1 Simon Fraser (smfr) 2017-01-26 20:01:26 PST 
Created attachment 299899 [details]
Patch for EWS
Comment 2 Simon Fraser (smfr) 2017-01-26 20:01:57 PST 
rdar://problem/29453068
Comment 3 Simon Fraser (smfr) 2017-01-27 20:36:26 PST 
Created attachment 299993 [details]
Patch
Comment 4 Simon Fraser (smfr) 2017-01-27 20:43:01 PST 
Created attachment 299995 [details]
Patch
Comment 5 Build Bot 2017-01-27 22:01:50 PST 
Comment on attachment 299995 [details]
Patch

Attachment 299995 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/2961799

New failing tests:
compositing/geometry/fixed-in-composited.html
css3/filters/backdrop/dynamic-with-clip-path.html
Comment 6 Build Bot 2017-01-27 22:01:53 PST 
Created attachment 299997 [details]
Archive of layout-test-results from ews121 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews121  Port: ios-simulator-wk2  Platform: Mac OS X 10.11.6
Comment 7 Dean Jackson 2017-01-30 10:41:47 PST 
Comment on attachment 299995 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=299995&action=review

Would be cool to have a test that combines this with scroll snapping.

> Source/WebCore/ChangeLog:18
> +        Also add a way to do unconstrained scrollTo(), so that a test can call window.scrollTo(-10, -10) to
> +        simulate rubberbanding.

👍

> Source/WebCore/page/FrameView.cpp:1812
> +    bool allowRubberbanding = fixedBehavior == StickToViewportBounds;

Isn't rubber-banding two words? allowRubberBanding.

> Source/WebCore/page/FrameView.cpp:1818
> +        bool rubberbandingAtRight = allowRubberbanding && (visualViewport.maxX() - layoutViewport.width()) > stableLayoutViewportOriginMax.x();

Why do you -layoutViewport.width() here? Don't you want to rubberband at the right-most edge? I obviously misunderstand.

> Source/WebCore/page/FrameView.cpp:1830
> +        if (!rubberbandingAtRight && layoutViewportOrigin.x() > stableLayoutViewportOriginMax.x())
> +            layoutViewportOrigin.setX(stableLayoutViewportOriginMax.x());

Just writing this to see if it reads better:

if (!rubberbandingAtRight)
  layoutViewportOrigin.setX(std::min(layoutViewportOrigin.x(), stableLayoutViewportOriginMax.x());

Hmmm... whatever.
Comment 8 Simon Fraser (smfr) 2017-01-30 11:48:37 PST 
https://trac.webkit.org/r211379