Bug 206227 - Fixed elements no longer stay fixed with elastic overscroll (rubberbanding)
Summary: Fixed elements no longer stay fixed with elastic overscroll (rubberbanding)
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Scrolling (show other bugs)
Version: Safari 13
Hardware: Mac macOS 10.15
: P2 Major
Assignee: Simon Fraser (smfr)
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-01-14 05:30 PST by cc.glows
Modified: 2022-12-20 07:57 PST (History)
21 users (show)

See Also:

Attachments
Demonstration of the minimal example (554.44 KB, video/quicktime)
2020-01-14 05:30 PST, cc.glows 		no flags Details
Patch (71.85 KB, patch)
2020-01-22 18:32 PST, Simon Fraser (smfr) 		no flags Details | Formatted Diff | Diff
Patch (77.15 KB, patch)
2020-01-22 18:51 PST, Simon Fraser (smfr) 		koivisto: review+
commit-queue: commit-queue-
Details | Formatted Diff | Diff
Show Obsolete (1) 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 cc.glows 2020-01-14 05:30:04 PST 
Created attachment 387647 [details]
Demonstration of the minimal example

Minimal Example:

```html
<style>
  body {
    height: 2000px;
    margin: 0;
  }

  #fixed {
    position: fixed;
    top: 0;
    background: black;
    width: 100%;
    height: 100px;
  }
</style>

<div id="fixed"></div>
```

In earlier versions of macOS Safari (and current iOS Safari), the fixed header would stay fixed **including** the elastic overscroll. Now, it's not fixed when overscroll is in progress (like Chrome - which seems incorrect).

The problem here is that positioning libraries using `position: fixed` include window scroll to position elements, and Safari reports the overscroll included in the window.pageYOffset value, but since it's no longer fixed with it, the position is wrong when elastic scroll is in progress.
Comment 1 Radar WebKit Bug Importer 2020-01-17 23:43:23 PST 
<rdar://problem/58707084>
Comment 2 Simon Fraser (smfr) 2020-01-21 13:13:59 PST 
I think we broke this in the big scrolling tree rewrite.
Comment 3 Simon Fraser (smfr) 2020-01-22 18:32:11 PST 
Created attachment 388505 [details]
Patch
Comment 4 Simon Fraser (smfr) 2020-01-22 18:51:50 PST 
Created attachment 388508 [details]
Patch
Comment 5 WebKit Commit Bot 2020-01-23 09:57:53 PST 
Comment on attachment 388508 [details]
Patch

Rejecting attachment 388508 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'validate-changelog', '--check-oops', '--non-interactive', 388508, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

ChangeLog entry in LayoutTests/ChangeLog is not at the top of the file.

Full output: https://webkit-queues.webkit.org/results/13310483
Comment 6 Simon Fraser (smfr) 2020-01-23 13:53:44 PST 
https://trac.webkit.org/r255037
Comment 7 Simon Fraser (smfr) 2020-02-12 15:20:36 PST 
This was partially reverted in r256400.
Comment 8 Hiroyuki Ikezoe 2021-05-19 16:52:49 PDT 
I raised a spec issue (it's more or less a question though) about this behavior. https://github.com/w3c/csswg-drafts/issues/6299
Comment 9 Bramus 2022-08-09 03:41:55 PDT 
Just a heads up that Chrome M105 will include this changed behavior (See https://chromestatus.com/feature/5381155556687872). Firefox already includes it as of Firefox 89.
Comment 10 Bramus 2022-12-20 07:57:23 PST 
Testing again in MobileSafari and Safari I noticed that MobileSafari does the right thing and doesn’t move the FixedPos elements upon bounce. I don’t think this was always the case, so happy to see MobileSafari follow the spec here.

Safari on Desktop (TP 160) however does still bounce the FixedPos elements, making it the outlier when comparing behaviors across all major browsers.

Spec: https://drafts.csswg.org/css-overscroll-1/#overscroll-positioned