Default search scroll overflow

[OliverSpeir]

iOS Safari 18.6.2, I see this behavior on https://starlight.astro.build

Describe the Bug

When scroll overflows/propogates onto the page beneath the search modal I cannot scroll all the way back to see the search bar/close button.

I noticed this only happens when I tap on one of the results to then drag to scroll, if I tap+scroll somewhere other than a result link the scroll doesn't overflow.

Also noticed that closing the keyboard allows me to scroll all the way up to the search bar

ScreenRecording_09-22-2025.19-12-49_1.mov

[delucis]

Oh, Safari… 😭

I can’t reproduce in the iOS Simulator and don’t have an iPhone to test on.

In theory, the page below shouldn’t scroll like this — we apply a data attribute when opening the search modal to scroll lock the page:

starlight/packages/starlight/components/Search.astro

Lines 298 to 300 in 5787485

	[data-search-modal-open] {
	overflow: hidden;
	}

Any chance you could debug a bit to figure out what’s up?

[mayank99]

overflow: hidden still leaves the scroll container intact. If you want to lock scroll completely, then overflow: clip could be worth trying.

[delucis]

Thanks for the hint @mayank99! @OliverSpeir any chance you could try that code change and see if it helps?

[OliverSpeir]

Tried it, no luck. Only thing I've got so far is position fixed on [data-search-modal-open], but I haven't properly dug in yet

Traveling this weekend but on monday I can try again.

[HiDeoo]

Did some investigations on this one and I think the issue we are currently facing is this old bug in WebKit where basically, when the keyboard becomes visible, the viewport is not resized but instead, the keyboard covers part of it, so it becomes scrollable.

A more visible representation of this issue can be seen in the video below where as soon as the keyboard appears, the keyboard covers part of the viewport, and the viewport becomes scrollable.

ScreenRecording_01-16-2026.10-56-05_1.MP4

When we have results, and enough to have a scroll container in the dialog, we get 2 scrollable containers: the entire viewport and the dialog frame with the results.

ScreenRecording_01-16-2026.10-57-01_1.MP4

I tried various workarounds but the best I could come up with so far (inspired by the react-aria approach) is basically blocking the body scroll altho this means that some parts of the results might be hidden behind the keyboard and you need to close the keyboard to see them.

ScreenRecording_01-16-2026.10-58-09_1.MP4

I'm not sure if it's better or not so far, I'm tempted to say it's a bit better as I think it may be more obvious that the keyboard hides some content and dismissing it reveals it, vs having conflicting scrollable containers.

I'll try to do some more investigations and see if we can find a better solution. Open to suggestions if anyone has any idea!

[delucis]

Thanks for the great investigation @HiDeoo! I wonder if we could use env(safe-area-inset-bottom, 0px) somewhere to control the height of the search results container with the iOS keyboard revealed? (See e.g. “Keyboard-aware inputs”)

[HiDeoo]

Thanks for the great investigation @HiDeoo! I wonder if we could use env(safe-area-inset-bottom, 0px) somewhere to control the height of the search results container with the iOS keyboard revealed? (See e.g. “Keyboard-aware inputs”)

Afaik, based on my experience with it and also by quickly testing it out, env(safe-area-inset-bottom, 0px) would not work here.

safe-area-inset-bottom is used to get the bottom inset value to accommodate devices with notches or home indicators. For example, in the following video, the green Hello div is using the following CSS:

background: green;
padding-left: env(safe-area-inset-left);
padding-right: env(safe-area-inset-right);
padding-top: env(safe-area-inset-top);
padding-bottom: env(safe-area-inset-bottom);

demo.mov

By default, in portrait mode, no margin on my phone are added. When I switch to landscape mode, the div gets bottom padding to accommodate the home indicator. Triggering the keyboard does not change such values (and it's in fact a bug as it should become 0 when the keyboard is shown, but even without that issue, it would not help here).

[delucis]

Oh, interesting. In the iOS simulator the CodePen example linked in that CSS Tricks article works: https://codepen.io/drprime01/full/raaBKyW

bottom.mov

[HiDeoo]

Oh, interesting. In the iOS simulator the CodePen example linked in that CSS Tricks article works: codepen.io/drprime01/full/raaBKyW

Yeah, same on a device altho I think env(safe-area-inset-bottom) is always 0 so 0px + 10px is always 10px and the input stays above the keyboard due to iOS scrolling and zooming the viewport on the input so it's positioned like this.

In fact, replacing bottom: calc(env(safe-area-inset-bottom, 0px) + 10px); by bottom: 10px; for me provides the same behavior on a device:

demo.MP4

If you do the same on a simulator, does this change anything on your end?

[delucis]

Oh you’re right, it is scrolling up. I totally missed that 😅

[delucis]

The more research I do, the more I lean towards iOS deserving to be broken 😓

• Can’t use dvh to set the container height because it doesn’t react to keyboards
• Can’t use env(keyboard-inset-*) because it’s not available on iOS
• Can’t use the visualViewport JS API because its resize event doesn’t fire for the keyboard expansion (at least in my test with iOS simulator)

Not sure if there are other options left that I haven’t considered.

[HiDeoo]

Not sure if there are other options left that I haven’t considered.

If we're talking about "sane" options, I think that's the end of the list.

Considering this is a side-bug of a workaround for another issue, when using the approach used by react-aria, I'm wondering if it becomes an acceptable one considering all the curent limitations 😢

[delucis]

Ah one more thought comes to mind: given this is not a generic issue and only related to the search input, we could maybe use focusin/focusout events on the input to trigger a resize of the modal for scrolling?

[HiDeoo]

Ah one more thought comes to mind: given this is not a generic issue and only related to the search input, we could maybe use focusin/focusout events on the input to trigger a resize of the modal for scrolling?

I guess the question would become: can we reliably determine the new size without hardcoding a keyboard height (which can change), only do that on devices where it's an issue, and also still works reliably when the user zoom-in/out using pinch to zoom 😅

As far as I know, I failed to do so in my last attempt but I'll try to play a bit more with it when I get some time.

[delucis]

Yeah those are all big questions 😅 No idea and not sure if it’s a valuable area to spend too much time, maintenance, or code on.