I don’t see an attached Gerrit change, what should we review?

Change #1270949 had a related patch set uploaded (by Hasan Akgün (WMDE); author: Hasan Akgün (WMDE)):

[mediawiki/extensions/Wikibase@master] Update modal height and add guard styles for iOS scrolling bug

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

Test wiki created on Patch demo by Audrey Penven (WMDE) using patch(es) linked to this task:
https://873047448a.catalyst.wmcloud.org/w/

Change #1270949 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Update modal height and add guard styles for iOS scrolling bug

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

Testing the unmerged patch on a real iphone turned out to be basically impossible. Therefore I merged the patch after judging it as safe enough to try. Testing on beta revealed a problem: the footer buttons are slightly cut off, though they are still clickable:

screenshot from testing on an iphone 12 mini:

There's more space under the buttons than I'd expect, but this might be an unavoidable problem, given how bad iOS26 is. I'm curious what this looks like on Android.

Tests on android confirm that the extra space is unique to iOS.

Some additional experimentation on iOS shows that Safari's rounded UI elements (address bar + navigation) have a white background rectangle. The footer itself has the expected height, but blends visually with the background of the navigation elements below. It is unclear if or how we can fix the visual height for only iOS devices.

TV: We can still specifying certain style targeting the IOS devices only to control the footer height either with JS or css:
JS:

const isIOS = /iPad|iPhone|iPod/.test(navigator.userAgent);

if (isIOS) {
    document.body.classList.add('ios');
}

css:

@supports (-webkit-overflow-scrolling: touch) {
    .my-element {
        height: 500px;
    }
}

(Note: Fix footer buttons on edit modal belongs to this task but wasn’t attached properly.)

task time:

• @Arian_Bozorg reviewed ios padding in T418110#11902404 and agreed to decline this optimization

I tried to reproduce this locally with an iOS Simulator and a standalone page using the same CSS from modalOverlay.vue.

It looks like the problem is that when iOS keyboard opens, 100dvh on body shrinks and causes a small scroll leak (body.scrollTop goes from 0 to ~15px). Also the modal height: 100% does not adapt to the keyboard, so the footer gets pushed out of view.

I tried a small fix with three parts:

1) Listen to window.visualViewport resize events and set modal height dynamically so footer stays above the keyboard:

if ( window.visualViewport ) {
    this.resizeHandler = () => {
        this.$el.style.height = window.visualViewport.height + 'px';
    };
    window.visualViewport.addEventListener( 'resize', this.resizeHandler );
    this.resizeHandler();
}

2) In body guard CSS, remove height: 100dvh and use touch-action: none instead:

 body.wikibase-wbui2025-modal-open {
     overflow: hidden;
-    overscroll-behavior-y: none;
     position: fixed;
-    height: @size-viewport-height-full;
+    width: 100%;
+    touch-action: none;
+    overscroll-behavior: none;
 }

3) Save scroll position before opening modal and restore it on close, so user does not lose their place on the page:

 mounted() {
+    this.savedScrollY = window.scrollY;
     document.body.classList.add( 'wikibase-wbui2025-modal-open' );
+    document.body.style.top = -this.savedScrollY + 'px';
 },
 unmounted() {
     ...
         document.body.classList.remove( 'wikibase-wbui2025-modal-open' );
+        document.body.style.top = '';
+        window.scrollTo( 0, this.savedScrollY );
 }

visualViewport is supported since Safari 13 so it should cover all active iOS versions. Happy to put a patch on Gerrit if the approach looks ok.