Bug 300965 – REGRESSION (iOS 26): Dialog backdrop looks weird, as it doesn't extend below address bar

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Alex]

Created attachment 477113 [details]
Screenshot of a native <dialog> tag with native ::backdrop that does not cover that see-through address bar

I don't know how to summarize this, to be honest. Did you even test this thing? 

Nobody thought that there might be websites with a fullscreen overlay when you came up with this transparent address bar idea? 

NOBODY thought that there's a NATIVE dialog tag with a fullpage overlay? 

You should be ashamed of yourself shipping this garbage at 3+ trillion at capitalization. This is what native dialog looks like on iOS26. Why must I explain to our customers that their top-tier devices are incapable of rendering web pages and it's not our fault and there's nothing we can do?

[Alexey Proskuryakov]

Please provide a test case. This certainly isn't something that affects many websites in a negative way.

[Alex]

Created attachment 477120 [details]
Apple's own store page in iOS 26

[Alex]

You're joking, right?

The test case is "document.querySelector('dialog').openModal()"

This affects ANY website that has any full screen overlay, any implementation of modals, bottom sheets, drawers, positioned sidebars. I thought I was too harsh on you guys because you should be CLEARLY aware of that, but you seem to think it's not a big deal!?

Here's a test case for you, your own front page store (added as second attachment):
https://www.apple.com/shop/buy-ipad/ipad-pro

[Alexey Proskuryakov]

I opened https://www.apple.com/shop/buy-ipad/ipad-pro, tapped on "Learn more" about Apple Intelligence, and scrolled. I cannot reproduce the issue there. 

Perhaps it's already fixed in newer WebKit that I have on my device, but either way I can't know whether your original report was about the same problem, or confused between similar yet distinct issues.

[Alex]

I've had the latest version. Apparently current betas changed something, I tried the latest beta and Apple's website is indeed fixed. I have created a very basic demo of 4 different approaches:

1. Native dialog
2. Emulated dialog with overlay
3. Emulated dialog with backdrop-filter
4. Emulated bottom sheet

3 out of 4 are completely broken:

1. Native dialog's overlay still does not work
2. Emulated dialog with overlay turns the address bar full black
3. Emulated dialog with backdrop-filter does not affect those areas at all
4. Emulated bottom sheet is the least broken of all, just showing a see-through slid whenever address bar is shrinking

I'll attach the HTML reproduction and a video recording that was done using latest iOS26.1 beta

In my real life code though, not in the isolated case, the black address bar never comes back to transparent and remains black after modal is closed. I will try to reproduce this as well later.

Now to the solutions:

How you obviously should have approached that is to make the viewport entire screen. Because I can LITERALLY view the page down there. And have this area covered by the env(safe-area) because this is exactly what it was created for.

Nobody's on the web is using env(safe-area), though, that's what you probably thought (if you hopefully thought anything at all, given the state of the public release over a month in). So instead you're locked yourself in the guessing games trying to color those pixels to match which just a bandaid quick-slap fix that is not working as you can see from my test cases.

So possible approaches are:
1. Backtrack to the proper solution using env(safe-area), it is not too late to admit you screwed up on that one and do the right thing.
2. Give us an API to control this area color and transparency so we can pick up your slack ourselves as we usually have to do.

[Alex]

Created attachment 477122 [details]
Screen recording of 4 different basic fullscreen overlay based elements

[Alex]

Created attachment 477123 [details]
Reproduction web page in a single file

[Alexey Proskuryakov]

Thank you for the repro case. I can reproduce the issue with dialog.showModal() backdrop, and this looks wrong to me indeed.

We'd likely need separate reports for the others. 
- I cannot reproduce #2 with a newer WebKit build that I have on my device, the address bar does not turn black. 
  - Although just like in your video, a crack appears while scrolling. Given that everything is done with CSS here, it looks like a bug, but not necessarily an iOS 26 regression. Separate analysis will be needed there.
- #3 reproduces as in the video recording, however I'm unsure if it's a bug or expected behavior. It doesn't look terrible to my eyes. CC'ed experts will know better.
- #4 definitely looks wrong, perhaps same issue as the crack in #2.

[Radar WebKit Bug Importer]

<rdar://problem/162985065>

[Alex]

#3 looks absolutely terrible, it is clearly broken and needs fixing. What if our modals have backdrop-filter of blurring everything behind and this piece is see-through and unblurred? The issue with see-through address bar is not just color, which I guess you thought at first, when you tried to patch that thing with color autodetection.

Stop dancing around the issue, you cannot fix it unless you admit it's broken. I'm happy to shower you with examples, if that's what it takes.

The address bar on iOS 26 Safari is a design decision that I am not arguing against. But it IS broken in implementation. It needs to be env(safe-area), it is perfectly clear, this is exactly what this concept was made for.

I don't like that you limit this issue to the native dialog backdrop. The issue is much wider in its nature, the native dialog backdrop is just a blatant example of what you definitely should have had covered before public release, given it's native and a responsibility of the browser.

[Svyatoslav Zaytsev]

Expect fix this issue in the next five years :)) (not exactly)

I confirm the issue with viewport in Safari on iOS26.
Viewport preference «viewport-fit=cover» doesn’t work as it should. Viewport doesn’t fit entire screen. By idea with this viewport parameters my document should fit whole screen from edge to edge. And with env() variables i should be able to adjust it properly to avoid overlapping with Safari UI elements.
And viewport looks completely broken when I'm trying to open modal dialog. Let’s say I have light background color on my page, so areas of address bar and dynamic island have lidht background too. When I'm opening dialog which ::backdrop has semi-transparent dark background color, ::backdrop doesn’t fit entire viewport as it should, so areas under dynamic island and address bar are still light. it’s looks ugly. Looks like viewport of ::backdrop is not the same size as viewport of document.

To fix this fatal issue you have to:
- make viewport fit entire screen when viewport-fit=cover
- env(safe-area-inset-top) must be equal to height of dynamic island area
- env(safe-area-inset-bottom) must be equal to height of address bar area, and it must me dynamic for cases when address bas is collapsed.
- ::backdrop must fit whole screen, and it should not have any gaps between screen edges when viewport-fit=cover

[Alexey Proskuryakov]

Please don't extend the scope of the bug if you want it fixed. Tracking multiple issues in one Bugzilla bug is the recipe for never getting it fixed. Any other issues besides the one with dialog.showModal() backdrop need to be tracked in separate bugs.

[Alex]

If you change it to native dialog you can rig this thing for dialog specifically with another hack on your side and call it a day. Native dialogs is the least of the problems here.

This issue is about viewport not covering address bar area, EVERYTHING else gets fixed automatically once the real issue is addressed. I have updated the title of this issue to most accurately represent it as single issue as you advised, let's keep it about this. Thank you alex.skakun for correctly pointing out/identifying <meta name="viewport"> as the root source:

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#viewport-fit

> cover: The viewport is scaled to fill the device display. It's highly recommended to use the safe area inset variables to ensure that important content doesn't end up outside the display.

Same with height=device-height:

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#height

> special value device-height, which is the physical size of the device screen in CSS pixels

This is not working and this must be fixed.

[Alexey Proskuryakov]

I don't think that your suggestion for course of action is correct. I understand where you are coming from, and your point of view will be considered. We will track the symptom that is definitely a bug, and further attempts to change the scope will be considered to be vandalism.

[Alex]

You might think whatever you want, fact is this is still a bug and a regression. I have filed a separate issue with a dedicated reproduction. For anyone stumbling upon this looking for custom dialogs fix, you can track it here:
https://bugs.webkit.org/show_bug.cgi?id=301108

The real vandalism here is iOS26 and lack of consideration on your part when breaking every full page content on the web.

[Wenson Hsieh]

Pull request: https://github.com/WebKit/WebKit/pull/52753

[EWS]

Committed 301911@main (2ae949b78743): <https://commits.webkit.org/301911@main>

Reviewed commits have been landed. Closing PR #52753 and removing active labels.

[Wenson Hsieh]

*** Bug 302272 has been marked as a duplicate of this bug. ***

[Alex]

You know we can style those things, right? Still broken:

#backdrop::backdrop {
  backdrop-filter: brightness(0.25);
}

#gradient::backdrop {
  background: linear-gradient(to right, black, transparent);
}

[Alex]

Created attachment 477492 [details]
Another reproduction with styles that are still broken

[Alexey Proskuryakov]

OK, please file a new bug. This one was fixed, and it's not OK to create new variations after the fact.

[Alex]

This bug was not fixed. The title is "Dialog backdrop looks weird, as it doesn't extend below address bar" and this is still true.

[Alex]

Why are you resolving the issue if it is not fixed? You yourself change the title of my issue to that and this is still true, the backdrop still does not extend below address bar and still looks weird. You can call me vandal all you want but you are just papering over the cracks here and cooking the books by considering this issue resolved and I want this to be noted for posterity. My code uses backdrop-filter and it is still broken and my customer still come to me asking why it is broken.

[Alexey Proskuryakov]

It's unclear to me what makes you so interested in tracking all vaguely related issues in one bug report. Whether resolved/fixed or open, it is currently in a confusing state that will not result in further code changes. If you want to impact WebKit's behavior, please file a new bug, and it will be considered on its merits. Your specific examples of designs that what you want to implement are valuable, and are likely to inform further improvements in WebKit.

I understand that you have a solution in mind that seems obvious and straightforward to you. At this point, we believe that this obvious solution would break more websites than it would fix.

[Alex]

You have not resolved anything, you've put bandaid on a default browser presentation of native dialog and called it a day. It is not vaguely related, it is directly related. You just don't like it because your idea of a fix is failing as soon as something is not perfectly aligned with the conditions your fix "needs". We're heading into 3 releases of iOS26 with broken web, it is absolutely pathetic and shameful. How on earth did you not foresee this when you came up with the transparent address bar in the first place is beyond me. In over a decade of being webdev I had the lowest expectations of webkit engrained into me but you've managed to outdo yourself this time.

Here's a separate issue for dialog backdrop:
https://bugs.webkit.org/show_bug.cgi?id=303167

Hi,

I too am hitting this bug.  I've attached a couple of screenshots here: https://dropover.cloud/a8bd38

Hitting it at the top and bottom of Safari on iOS.  I'd expect the backdrop to extend up into the header and down where the address bar is.  It looks weird as it is.   I'd expect all content to be in that area too and we use the safe inset vars to padd the bottom to ensure all content is visible.

Thanks,
Neil

[Alexey Proskuryakov]

Thank you Neil. This may or may not be already fixed, I cannot know without a way to reproduce. If you'd like us to look into this, please file a new bug with steps to reproduce.

(In reply to Alexey Proskuryakov from comment #28)
> Thank you Neil. This may or may not be already fixed, I cannot know without
> a way to reproduce. If you'd like us to look into this, please file a new
> bug with steps to reproduce.

Hi Alexey,

Thanks for the reply.  in actual fact you can view the site live at neiltonge.co.uk.

Please take a look and see what you think.  The dialog opens with the menu button at the top right only in small screen sizes.

(In reply to Alexey Proskuryakov from comment #28)
> Thank you Neil. This may or may not be already fixed, I cannot know without
> a way to reproduce. If you'd like us to look into this, please file a new
> bug with steps to reproduce.

Hi Alexey,

Thanks for the reply.  in actual fact you can view the site live at neiltonge.co.uk.

Please take a look and see what you think.  The dialog opens with the menu button at the top right only in small screen sizes.

(In reply to Alexey Proskuryakov from comment #28)
> Thank you Neil. This may or may not be already fixed, I cannot know without
> a way to reproduce. If you'd like us to look into this, please file a new
> bug with steps to reproduce.

Hi Alexey,

Thanks for the reply.  in actual fact you can view the site live at neiltonge.co.uk.

Please take a look and see what you think.  The dialog opens with the menu button at the top right only in small screen sizes.

[Alexey Proskuryakov]

I think that it's fixed - in that the situation is detected, and both top and bottom become solid color once the side menu shows up. In fact, it's better than iOS 18.x, as it had the same general issue - page content showed up behind address bar, and menu didn't. It was just much less noticeable in iOS 18.x, as there was very strong blur.