Yep, I can confirm this on my iPad Air (iOS 7.1) when not using an external Bluetooth keyboard.

In landscape mode with the keyboard open there is *very* little vertical space, only about 220px high, between the VE toolbar and the top of the keyboard -- vertically laid-out menus are probably not a good idea here.

iOS text-selection menus tend to be laid out horizontally like a segmented toolbar presented as a popup from the selection itself; Android 4.x uses a horizontal action bar at the top of the screen.

I would recommend going with some sort of horizontal button layout, perhaps as a second layer of toolbar.

Hmm, this sounds like a bug related to ClippableElement. The menu should automatically clip and become scrollable when there isn't enough screen space for it. You can see this on desktop if you resize the window. Maybe iOS Safari isn't emitting a resize event, or is emitting an event we're not listening to, or isn't giving us the correct viewport dimensions?

(In reply to Roan Kattouw from comment #2)

Hmm, this sounds like a bug related to ClippableElement. The menu should
automatically clip and become scrollable when there isn't enough screen
space for it. You can see this on desktop if you resize the window. Maybe
iOS Safari isn't emitting a resize event, or is emitting an event we're not
listening to, or isn't giving us the correct viewport dimensions?

Juliusz explained to me that there's a bug in iOS Safari when the keyboard comes up: the viewport becomes smaller, but measuring the viewport does not take this into account. The hack Juliusz is currently using in MobileFrontend to compensate for this is to arrange the document such that the main viewport never scrolls, instead everything is wrapped in a scrollable <div> that's exactly the size of the viewport. Then he listens for focus events, and attempts to scroll the viewport down by a large amount (9999px or something?). Under normal circumstances, this has no effect, but if the keyboard is up, the viewport will be scrollable and measuring how much it scrolled by gives you the height of the keyboard. He then adjusts the sizing of the wrapper <div> so it once again fits the viewport exactly.

This is also part of why things sometimes behave very strangely when focus events are dropped or emitted at the wrong time, because then Juliusz's code may not notice that the keyboard has appeared or disappeared, and it may not adjust the size of the wrapper <div> when it should.

To address this bug, we would have to have menus clip to this wrapper div rather than the body, and we would have to have them reevaluate their clipping state (by calling .clip()) every time this wrapper <div> is resized.

Bumping over to Bartosz; this is an awkward three-way bug between VE, MobileFrontend and OOUI as I understand it. Fun. :-(

(In reply to Roan Kattouw from comment #3)

Juliusz explained to me that there's a bug in iOS Safari when the keyboard
comes up: the viewport becomes smaller, but measuring the viewport does not
take this into account. The hack Juliusz is currently using in
MobileFrontend to compensate for this is to arrange the document such that
the main viewport never scrolls, instead everything is wrapped in a
scrollable <div> that's exactly the size of the viewport.

This seems to be _fixIosHeader() in /javascripts/Overlay.js in MF.

To address this bug, we would have to have menus clip to this wrapper div
rather than the body, and we would have to have them reevaluate their
clipping state (by calling .clip()) every time this wrapper <div> is resized.

Why doesn't this already work? ClippableElements are supposed to be clipped to the closest scrollable element, and surely the MF overlay is closer than body.

I attempted to reproduce this using CrossBrowserTesting.com, but whenever I click on the "Cite" icon using it, the entire toolbar disappears. I can't tell if it's a real bug or the testing app being broken. All in all, this was a wonderful waste of time and I'm still unable to debug, much less fix, this bug (and I still believe it shouldn't be accurring anyway in the first place per comment 5).

Confirming that, it is still occurring.