Safe areas ignored after navigating a WebView/WebPage back in a NavigationStack

Question

Created 2w

Replies 3

Boosts 1

Participants 3

I'm using the new iOS 26 WebPage/WebView for SwiftUI in a NavigationStack. The initial load works as expected, but when loading items from the back/forward lists, the content jumps beneath the navigation bar:

struct WebPageTestView: View {
    var webPage = WebPage()

    var body: some View {
        NavigationStack {
            WebView(webPage)
                .toolbar {
                    Button("Back") {
                        if let backItem = webPage.backForwardList.backList.last {
                            webPage.load(backItem)
                        }
                    }
                    
                    Button("Forward") {
                        if let forwardItem = webPage.backForwardList.forwardList.first {
                            webPage.load(forwardItem)
                        }
                    }
                }
        }
        .task {
            webPage.isInspectable = true
            webPage.load(URL(string: "https://domchristie.co.uk/"))
        }
    }
}

I have run this on the iOS 26.0 and 26.1 Simulators and get the same issue.

The demo website does not use any JavaScript.

I was able to replicate this behaviour using a wrapped WKWebView and calling the .ignoresSafeArea(.all) modifier.

Boost

Answer 1

jwcarr OP

1w

Yes, I'm having the same problem (with a wrapped WKWebView, but presumably also the new WebView).

The jumping-on-back-button issue was also a problem before iOS 26, but you could work around it by using

.ignoresSafeArea(.all, edges: .bottom)

However, now in iOS 26, Apple wants the content to flow behind the toolbar, meaning the above fix is no longer suitable.

Did you manage to find a workaround?

0

Answer 2

DTS Engineer OP

Apple

1w

Are you able to reproduce this problem using the following sample?

https://github.com/WebKit/WebKit/blob/cb619a3e3f54e69f1b46d36645b46606f9d12c9c/Tools/SwiftBrowser/Source/Views/ContentView.swift#L29

If you are then our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports.

If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why?

0

Answer 3

jwcarr OP

1w

I filed a bug report (FB20465338) but I also want to note some more details here in case this is useful to someone:

When navigating back/forward in a WebView or WKWebView, the page suddenly jumps up. The reason appears to be that WebKit automatically adds some padding to the top of the webpage to account for the unsafe nav bar area, but it then forgets to account for this padding when navigating back/forward. The effect is especially pronounced if you swipe back/forward. When swiping you see a static preview of the incoming page, but when you release the swipe, the page suddenly jumps up.

As far as I can tell, this has always been an issue, but before iOS 26 it wasn't really a problem because the WebView would usually be flush against a solid nav bar. However, in iOS 26, this bug is problematic because Apple is asking us to flow the web content behind the nav bar; indeed, this is the default behavior of a WebView.

There's effectively no good solution in iOS 26 because you basically have two choices:

Adopt the default behavior with the content flowing behind the nav bar; but then you get a janky back/forward experience.
Set .ignoresSafeArea(.all, edges: .bottom) so that the content does not flow behind the top nav bar, but then the nav bar is plain white/black and it looks bad for the content to just disappear abruptly without some kind of border or fade effect. This can't simply be solved by making the nav bar a different color because then you get into issues with the glass buttons and the floating iPad sidebar.

Would love to hear if someone figured out a workaround, even if it's just some styling to make Option 2 less bad.

0