I've left a comment on T218414 to address desired VE behavior. Regarding all other overlays, I think it's safe to say that the rule should be that the header remains fixed, regardless of the keyboard being open or closed. Perhaps there will be exceptions in the future, but it seems like a sensible starting point to keep them fixed by default.

Spoke with @Jdlrobson and now have more context here. As I understand it, on iOS (any browser) fixed elements only scroll away as the result of tapping into a <textarea> element (note this doesn't occur for <input>). Since the inconsistent behavior between Android and iOS is the result of an OS-level difference I don't think it's critical (or realistic) for us to have a consistent experience.

I think our rule should be something like: modal/overlay headers are fixed, aside from when a user is in a <textarea> element.

@Jdlrobson @matmarex is there any additional design input needed here? If not please let me know and I will move this out of our #nirzar-is-cool column.

As I understand it, on iOS (any browser) fixed elements only scroll away as the result of tapping into a <textarea> element (note this doesn't occur for <input>).

This isn't quite correct. The fixed elements scroll away whenever the keyboard is open. This includes tapping into a <textarea>, <input type=text> (or similar), <select>, or any contenteditable element (I'm not sure if this is a complete list).

Since the inconsistent behavior between Android and iOS is the result of an OS-level difference I don't think it's critical (or realistic) for us to have a consistent experience.

Sounds reasonable to me.

In T218415#5060261, @matmarex wrote:

As I understand it, on iOS (any browser) fixed elements only scroll away as the result of tapping into a <textarea> element (note this doesn't occur for <input>).

This isn't quite correct. The fixed elements scroll away whenever the keyboard is open. This includes tapping into a <textarea>, <input type=text> (or similar), <select>, or any contenteditable element (I'm not sure if this is a complete list).

For clarity: as far as I can tell the search header, which is an <input> element, remains fixed while the keyboard is up:

In T218415#5061724, @alexhollender wrote:

For clarity: as far as I can tell the search header, which is an <input> element, remains fixed while the keyboard is up:

It is visible when you initially open the keyboard, but it disappears when you scroll with the keyboard open.

I tested it and found that there is a weird inconsistent behavior where the keyboard will sometimes close when you start scrolling. I don't know why that happens, and when it does, then the header of course stays fixed. But if the keyboard doesn't close, the header scrolls out of view.

Recording:

Moving back to tech backlog as we're likely to look at Codex search for mobile in Q4

Per the web team's quarterly grooming, these tasks are being removed from the team's backlog.