This is correct behaviour as the bottom padding area is added to avoid having any links that would conflict with the bottom menu bar (clicking in that area just brings the menu bar up).

Hey @iamjessklein we need you to conduct a design review on this and determine if we can proceed as is or if we need to make tweaks.

Why this happens:

iOS Safari has a collapsible menu bar at the bottom of the screen, which hides when the page is scrolled:

When the menu bar is collapsed, any controls placed in that area (bottom 44px of the browser window) can't be tapped – instead, tapping there brings up the menu bar (and scrolls the entire page up by its height):

The design calls for the "Remove link" button to be placed at the bottom of the screen, so when the menu bar is collapsed, the user would effectively have to tap our button twice (first tap opens the menu bar and scrolls the button up; second tap, in the new position, actually executes the action).

To avoid this, we add extra space underneath it when the menu bar is collapsed, and remove it when the menu bar expands:

However, when the Safari menu bar collapses/expands, it has a slight animation. We can't sync our animation to it, because the browser does not notify us that this is happening until its own animation is done. Therefore our opposite animation for our empty space runs with a slight delay, and looks "wonky". Video:

What can we do about it?

• Perhaps removing our animation will make it feel better, but it'll still be pretty bad.
• We can remove our trick, and just deal with the fact that Safari users will have to tap on controls placed in this area twice.
• We could consider moving the buttons from that area elsewhere?

What can we do about it?

We could also style the fake padding differently to make it look more intentional.

I think we should just remove our workaround here. Its effect is surprising and distracting.

iOS users probably will not be surprised by having to tap twice on buttons in this area. And even if it surprises someone, the "Remove" actions should be used relatively rarely, and the surprising behavior does not cause much friction.

Change 526237 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] Remove hack to avoid iOS Safari menu bar area tap stealing

https://gerrit.wikimedia.org/r/526237

Change 526238 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[VisualEditor/VisualEditor@master] Remove hack to avoid iOS Safari menu bar area tap stealing

https://gerrit.wikimedia.org/r/526238

In T227628#5374147, @matmarex wrote:

the "Remove" actions should be used relatively rarely

You make a good point. There is another edge case that will be affected which are body-less contexts (gallery, math etc.) which have all their actions in the menu bar area:

We also observed in user testing that our estimate of the toolbar height (44px) is not quite enough on newer iPhones with notches.

The above patches by Bartosz propose removing the padding completely. We should make a decision on how to proceed:

1. Status quo: plain white padding
2. Re-style padding (e.g. grey background / border) to look more intentional
3. Remove padding

The hacks also seem to cause weird flickering when scrolling on iOS 13:

In T227628#5513046, @matmarex wrote:

The hacks also seem to cause weird flickering when scrolling on iOS 13:

@matmarex I'm experiencing the same behavior that's shown in the video you shared in T227628#5513046

In T227628#5374147, @matmarex wrote:

I think we should just remove our workaround here. Its effect is surprising and distracting.

iOS users probably will not be surprised by having to tap twice on buttons in this area. And even if it surprises someone, the "Remove" actions should be used relatively rarely, and the surprising behavior does not cause much friction.

I'm for what @matmarex is proposing in the quoted comment above for the reasons he also mentions in this same comment. Tho, @iamjessklein, I am curious what you think the best approach is.

Bartosz, a question in parallel for you:

• Has what's described in T227628#5374147 already been deployed? I ask considering I seem to be experiencing the "tapping twice" behavior [1] that I thought would come with us implementing this approach: T227628#5374147 (Please let me know if I've misunderstood something)

1. https://youtu.be/S6JQ2HRJNV0

In T227628#5638953, @ppelberg wrote:

Has what's described in T227628#5374147 already been deployed? I ask considering I seem to be experiencing the "tapping twice" behavior [1] that I thought would come with us implementing this approach: T227628#5374147 (Please let me know if I've misunderstood something)
https://youtu.be/S6JQ2HRJNV0

No, it hasn't been deployed, and it behaves as I described for me still:

Based on your video, it looks like the size of the browser menu bar, which we assumed to always be 44px, actually differs between different iPhone models. I guess it's because of the notches?

Compare these screenshots from my iPhone SE, where the height of the menu bar exactly matches the height of our extra space at the bottom of the screen, and the "Remove link" buttons appear in the same place on the screen:

…to these screenshots from your video (no idea what's the phone model), where they don't:

So if we wanted to keep our current workaround, we'd actually have to experiment with different phones to find the right values for each one (or maybe find documentation about this somewhere), and keep it updated as new models are released. Which seems pretty awful to me.

this looks better than the current experience +1

Change 526238 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] Remove hack to avoid iOS Safari menu bar area tap stealing

https://gerrit.wikimedia.org/r/526238

Change 526237 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Remove hack to avoid iOS Safari menu bar area tap stealing

https://gerrit.wikimedia.org/r/526237

Change 569597 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (daa98ac4e)

https://gerrit.wikimedia.org/r/569597

Change 569597 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (daa98ac4e)

https://gerrit.wikimedia.org/r/569597