Bug 297779 – [ios26 Beta 7] Fixed elements move up and down when the scroll direction changes

• Component: New Bugs
• Status: RESOLVED MOVED

[R_]

Created attachment 476488 [details]
IOS 26 Safari, showing a layout css bug,(fixed items should not move up and down)

Div elements with CSS position fixed will move up around 10px when use is scrolling.

Given the html or div content is larger than the viewport and scrolling is enabled.

The Safari address bar will minimize, as the user begins scrolling any fixed element  move up or down for a given mount when they should remain fixed.

video attached.

[Ahmad Saleem]

@R_ - can you share minimal HTML or CSS to reproduce this bug or either attach here?

[Radar WebKit Bug Importer]

<rdar://problem/159439271>

[Simon Fraser (smfr)]

If you kill and relaunch Safari, does this still reproduce? Is there some sequence of steps that trigger it?

Hey,

we are experiencing a similar problem with Safari on iOS 26.0 (23A340, iPhone 15). In short, sometimes it happens that a sticky header element gets pushed beyond the visual viewport by exactly 24px, and sometimes it stays there when you stop scrolling. **I've added an attachment above titled "Demo".**

**Details:** 

Suppose that we have a sticky nav element with `top: 0`. If you first open the page with Safari on iOS 26, everything works perfectly fine, even when you scroll. Then you click on a text input and dismiss the on-screen keyboard. Now if you scroll down, the sticky element gets pushed 24px beyond the visual viewport. I've noticed that `window.visualViewport.offsetTop` is set to `24`. If you reload the page, it won't help. Neither does switching tabs and coming back. Only closing and reopening Safari works. (Interestingly, if you have multiple tabs open, the issue spreads across all of them.)

A small demo can be found here: https://codesandbox.io/p/sandbox/gfm2s4

**Steps to reproduce:**

1. Visit this CSB in Safari: https://gfm2s4.csb.app/
2. Scoll to make sure everything works
3. Click the text input and dismiss the on-screen keyboard
4. Scroll again

You should notice that the gray bar at the top (and the debug box at the bottom) move up when you scroll down.

I think that problem relates to this one https://stackoverflow.com/questions/79753701/ios-26-safari-web-layouts-are-breaking-due-to-fixed-sticky-position-elements-g

Created attachment 476697 [details]
Another Demo Video

(In reply to lennox.schuster from comment #4)
> Hey,
> 
> we are experiencing a similar problem with Safari on iOS 26.0 (23A340,
> iPhone 15). In short, sometimes it happens that a sticky header element gets
> pushed beyond the visual viewport by exactly 24px, and sometimes it stays
> there when you stop scrolling. **I've added an attachment above titled
> "Demo".**
> 
> **Details:** 
> 
> Suppose that we have a sticky nav element with `top: 0`. If you first open
> the page with Safari on iOS 26, everything works perfectly fine, even when
> you scroll. Then you click on a text input and dismiss the on-screen
> keyboard. Now if you scroll down, the sticky element gets pushed 24px beyond
> the visual viewport. I've noticed that `window.visualViewport.offsetTop` is
> set to `24`. If you reload the page, it won't help. Neither does switching
> tabs and coming back. Only closing and reopening Safari works.
> (Interestingly, if you have multiple tabs open, the issue spreads across all
> of them.)
> 
> A small demo can be found here: https://codesandbox.io/p/sandbox/gfm2s4
> 
> **Steps to reproduce:**
> 
> 1. Visit this CSB in Safari: https://gfm2s4.csb.app/
> 2. Scoll to make sure everything works
> 3. Click the text input and dismiss the on-screen keyboard
> 4. Scroll again
> 
> You should notice that the gray bar at the top (and the debug box at the
> bottom) move up when you scroll down.
> 
> I think that problem relates to this one
> https://stackoverflow.com/questions/79753701/ios-26-safari-web-layouts-are-
> breaking-due-to-fixed-sticky-position-elements-g

Fixed, sorry, I meant a `position: fixed` element.

Is this being actively investigated? I am the original poster for https://stackoverflow.com/questions/79753701/ios-26-safari-web-layouts-are-breaking-due-to-fixed-sticky-position-elements-g - on our web applications, this is causing quite glaring issues with the UI. We were surprised this was not resolved with the general release of iOS 26 today, given how many websites (including the main page of apple.com) are affected by this very issue.

[Kris]

We're experiencing the same issue as described above, in the stackoverflow post, and here: https://developer.apple.com/forums/thread/800125... it unfortunately impacts thousands of sites using our software (discourse.org)  

As described there's a persistent 24px mismatch between window.innerHeight and visualViewport.height after opening the software keyboard — this is reproducible in the Apple developer forums too

Also experiencing this. In a WebView (Capacitor app) with a fixed bottom toolbar and a fixed icon near the top left of the screen, if a keyboard is brought up, on closing and then scrolling, the fixed elements move a bit on scrolling up/down as shown in other demonstrations.

[Wenson Hsieh]

Hi all — thank you for the reports!

After some investigation, this appears to be a bug in a system component. The fix isn't available in a developer beta yet, but we can update this bug when an iOS beta with the fix is available for testing.

[Maxoou]

Hi

I often integrate pop-ups/drawers that cover 100% of the width and 100% of the height of the screen.
Since iOS 26, the behavior on Safari has changed and it is no longer a true 100% height because of this floating bar.
The overlays of these pop-ups/drawers no longer cover 100% of the height, which looks very ugly.

(In reply to Wenson Hsieh from comment #10)
> Hi all — thank you for the reports!
> 
> After some investigation, this appears to be a bug in a system component.
> The fix isn't available in a developer beta yet, but we can update this bug
> when an iOS beta with the fix is available for testing.

Thanks a lot for the update — good to know it’s been tracked and a fix is on the way!

Just wanted to add: the same issue also happens in WKWebView, not only Safari. Our app relies heavily on webviews and we have a large user base, so this bug has a big impact on us.

Do you know if the fix will also cover WKWebView? And any rough idea on when it might land in an iOS 26 public release? We really care about the progress here.

[Wenson Hsieh]

The fix covers WKWebView in general (including Safari and embedding apps)

(In reply to cbrennan31 from comment #7)
> Is this being actively investigated? I am the original poster for
> https://stackoverflow.com/questions/79753701/ios-26-safari-web-layouts-are-
> breaking-due-to-fixed-sticky-position-elements-g - on our web applications,
> this is causing quite glaring issues with the UI. We were surprised this was
> not resolved with the general release of iOS 26 today, given how many
> websites (including the main page of apple.com) are affected by this very
> issue.

Strongly agree, urge Apple to resolve this bug as soon as possible.

[Milton]

(In reply to Radar WebKit Bug Importer from comment #2)
> <rdar://problem/159439271>

who will have access to rdar if u not work in apple dev team lol

[Colin Gourlay]

(In reply to Milton from comment #15)
> (In reply to Radar WebKit Bug Importer from comment #2)
> > <rdar://problem/159439271>
> 
> who will have access to rdar if u not work in apple dev team lol

Nobody! It's an internal URI scheme: https://en.wikipedia.org/wiki/List_of_URI_schemes#:~:text=rdar

Looks like this is fixed on Safari on the latest developer beta. Chrome on iOS is still an issue though

[R_]

(In reply to cbrennan31 from comment #17)
> Looks like this is fixed on Safari on the latest developer beta. Chrome on
> iOS is still an issue though

Thanks for you' re attention  concerning this bug. I'm the original poster.

Could you clarify on this being fixed? as  I posted this while I had beta 7 and even with the IO26 release the issue is still there.
Keep mind the bug title reads "Fixed elements...."

Unless there is another beta after IOS 26 release version where this have been fixed? 

Thank you

R_

[R_]

It is indeed fixed in Safari IOS 26.1 (beta)!

Thank you guys!

As for Chrome it looks like the Fixed elements moves as much as the lower toolbar height when it minimizes.

Still not working correctly for me in 2.61 beta - i.e. the fixed headers and footers are scrolling with the rest of the content and are above the other content too

Created attachment 476914 [details]
iOS 26.0 bug with `position: fixed` + `bottom: 0`

iOS 26.0 bug with `position: fixed` + `bottom: 0`

The `bottom: 0` is expected to match the lower edge of the screen with liquid glass controls floating on top - but instead matches the top part of these controls leaving big "hole" under the modal

Created attachment 476915 [details]
ios 26.0 and 26.1 dev beta bug

Hello!

Sorry for the previous comment — I’m new to WebKit Bugzilla and didn’t realize an attachment would immediately turn into an issue comment.

Since I’ve seen several similar reports (position: fixed + viewport size) redirected here, I’ll add my case too.

The attached screenshot shows modals for mobile devices styled as:
`position: fixed; top: 0; right: 0; left: 0; bottom: 0`

## Expected behavior

I believe that expected behavior should go like this:
1. `bottom: 0` should align with the actual bottom of the viewport (e.g. screen edge)
2. liquid glass controls should hover above the viewport at all times.
3. the liquid glass controls size is reported to css with e.g. `env(safe-area-inset-bottom)`

This way, users and website developers can adjust their design to these controls, for example by adding `padding-bottom: env(safe-area-inset-bottom)` to the modal content, or by making other design changes.

However, there is a risk of liquid glass controls overlapping with website controls and content on sites that have not added special handling for this case.

## Actual behavior

At iOS 26.0 (left part of the attached screenshot):
- `bottom: 0` corresponds to the top part of the controls
- This leaves a big "hole" in the modal, right under the controls - the main page of the website is visible through it.

At iOS 26.1 Developer Beta (right part of the attached screenshot):
- `bottom: 0` corresponds to the top part of the controls
- the "hole" is filled with what seems to be the "average" bg-color of the modal above

On this site, the gray fill doesn’t match the modal background and looks off

I’d prefer the "expected behavior", but if filling with color is the current decision, developers at least need a way to customize or adapt these colors. 🙏

[Simon Fraser (smfr)]

> However, there is a risk of liquid glass controls overlapping with website controls and content on sites that have not added special handling for this case.

Exactly, and it's pretty common for pages to have interactive controls at the bottom of a `position:fixed; inset: 0` which is why we chose to have bottom:0 be above the controls.  I don't think there's a viable alternative.

The bottom color fill is a heuristic, and could be improved (please let us know if you see bad cases).

> The bottom color fill is a heuristic, and could be improved (please let us know if you see bad cases).

It depends on what qualifies as a "bad" case, but in my attachment example from the previous comment:

https://bug-297779-attachments.webkit.org/attachment.cgi?id=476915

the fill color doesn’t match the modal background - it’s a darker shade of gray, and it looks off

> Exactly, and it's pretty common for pages to have interactive controls at the bottom of a `position:fixed; inset: 0` which is why we chose to have bottom:0 be above the controls.  I don't think there's a viable alternative.

I understand the reasoning, but still - could this be made configurable instead of a heuristic? 🤔

Something like a custom HTML meta tag:
```
<meta name="safari-liquid-glass-fallback-fill-color" content="#color" />
```
I would probably set this to the exact background color of the modals on the website

Or maybe something like this could work?
```
<meta name="safari-liquid-glass-viewport-offset" content="off" />
```
To enable true `bottom: 0` at the lower edge of the screen,`env(safe-area-inset-bottom)` with the size of the controls and "always-liquid" Safari controls

This would allow developers and designers to explicitly opt-in and adapt to the liquid glass ui manually in a way they see fit

---
I believe this approach would work better, because it avoids the "bad" heuristic discussion almost entirely 

If there is any customization option, and the best-effort heuristic looks "bad" on my website, then it’s me (the site developer) who should fix that and not the Safari developers.

[Wenson Hsieh]

(In reply to xad71rus from comment #24)
> https://bug-297779-attachments.webkit.org/attachment.cgi?id=476915
> 
> the fill color doesn’t match the modal background - it’s a darker shade of
> gray, and it looks off

Do you happen to have a full URL for the webpage in this screenshot? On https://www.aviasales.ru/?params=SFO1&service=naturecontent&contentId=4, the sampled color seems to match the background of the webpage (light gray). I think the darker gray in your screenshot is not expected.

[Jan]

Interestingly, I found that when I launch my Capacitor app (wrapping the web app) on iOS 26.1 Beta, it still doesn’t work. However, the issue seems mostly resolved when I open the same web app directly in Safari instead of inside the app container.

Is the WKWebView used by native apps not yet updated? Could that be why Chrome and other browsers don’t work either? Will WKWebView be updated to include the fix in the final 26.1 release? Thanks!

[Bramus]

(In reply to Jan from comment #26)
> Is the WKWebView used by native apps not yet updated? Could that be why
> Chrome and other browsers don’t work either? Will WKWebView be updated to
> include the fix in the final 26.1 release? Thanks!

For the Chrome issue, please refer to https://issues.chromium.org/issues/446714234

[Bramus]

(In reply to Simon Fraser (smfr) from comment #23)
> Exactly, and it's pretty common for pages to have interactive controls at
> the bottom of a `position:fixed; inset: 0` which is why we chose to have
> bottom:0 be above the controls.  I don't think there's a viable alternative.

This seems like a safe default to use, something that Chrome and other browsers do.

What I would expect, though, is that using `viewport-fit=cover` would affect this behavior, because that’s a signal from the author that they want the viewport to extend up to the screen’s edge and that they know what they are doing (while using the `safe-area-inset-*` envvars). On iOS, in portrait mode, this viewport meta tag does not seem to have an effect – something that is perhaps food for a follow-up bug.

(In reply to xad71rus from comment #24)
> I understand the reasoning, but still - could this be made configurable
> instead of a heuristic? 🤔
> 
> Something like a custom HTML meta tag:
> ```
> <meta name="safari-liquid-glass-fallback-fill-color" content="#color" />
> ```

Isn’t that exactly what `<meta name="theme-color">` was built for?

[Jan]

(In reply to Bramus from comment #27)
> (In reply to Jan from comment #26)
> > Is the WKWebView used by native apps not yet updated? Could that be why
> > Chrome and other browsers don’t work either? Will WKWebView be updated to
> > include the fix in the final 26.1 release? Thanks!
> 
> For the Chrome issue, please refer to
> https://issues.chromium.org/issues/446714234

Access to that Chromium issue is denied.

However, my main concern isn’t Chrome itself but native (/wrapped web) apps — it seems like people here might have insight into when WKWebView will receive this fix. Do you know if there’s any timeline or confirmation on when the updated WKWebView will ship?

> Do you happen to have a full URL for the webpage in this screenshot?

This one:
https://www.aviasales.ru/?params=MOW1&service=naturecontent&contentId=5
but yeah, it is basically the same modal that you found

> I think the darker gray in your screenshot is not expected.

Might depend on the device?
The screenshot was taken on one of the company’s testing devices, in this case an iPhone SE 2020

I will try to check some other devices too

> Isn’t that exactly what `<meta name="theme-color">` was built for?

The `theme-color` tag is often (in my experience at least) set to a bright, distinct "brand" color so the website stands out
For example, when the user looks at the "open tabs" screen
(Now that I think about it, it seems browsers stopped doing the "theme-colored tabs" thing some time ago 🤔)

This case feels different, since background colors are usually the exact opposite of "brand" colors - not distinctive at all

(In reply to Jan from comment #29)
> (In reply to Bramus from comment #27)
> > (In reply to Jan from comment #26)
> > > Is the WKWebView used by native apps not yet updated? Could that be why
> > > Chrome and other browsers don’t work either? Will WKWebView be updated to
> > > include the fix in the final 26.1 release? Thanks!
> > 
> > For the Chrome issue, please refer to
> > https://issues.chromium.org/issues/446714234
> 
> Access to that Chromium issue is denied.
> 
> However, my main concern isn’t Chrome itself but native (/wrapped web) apps
> — it seems like people here might have insight into when WKWebView will
> receive this fix. Do you know if there’s any timeline or confirmation on
> when the updated WKWebView will ship?

I have the same question. This is a rather impactful bug affecting many apps that use webview, so it would be great if someone from Apple could chime in on when the fix will be deployed.

(In reply to Wenson Hsieh from comment #25)
> (In reply to xad71rus from comment #24)
> > https://bug-297779-attachments.webkit.org/attachment.cgi?id=476915
> > 
> > the fill color doesn’t match the modal background - it’s a darker shade of
> > gray, and it looks off
> 
> Do you happen to have a full URL for the webpage in this screenshot? On
> https://www.aviasales.ru/?params=SFO1&service=naturecontent&contentId=4, the
> sampled color seems to match the background of the webpage (light gray). I
> think the darker gray in your screenshot is not expected.

Just checked out the iOS 26.1 release - fixed heuristic works now, there is no visible gap under liquid glass ui anymore

Thanks a lot!

This is not fully fixed. The problem can still be reproduced in iOS 26.1 and iPadOS 26.1.

Here is a video I made with iOS 26.1 still having the same bug, just a little bit more difficult to trigger. 

https://meta.discourse.org/t/ios-26-bugs-with-fixed-position-elements-in-discourse/382831/85?u=shauny