| Ryasmeen | |
| Mar 15 2019, 10:49 PM |
| F28395200: ScreenRecording_03-15-2019 15-36-49.mp4 | |
| Mar 15 2019, 10:49 PM |
Steps to replicate:
You will see part of the main article text being visible and scrolling up with that motion.
Screen capture attached:
This will happen when the browser address bar "collapses" (and available viewport area is enlarged), which is triggered by scrolling down. iOS Safari emits a window 'resize' event only after the small animation finishes, and until that happens, the dialog is not resized to cover the new enlarged browser viewport.
I suppose it might be enough to just put a small white rectangle in the "invisible" part of the page below the dialog, so that it covers the page underneath during the silly Safari animation. I didn't test this.
I tried it now. The approach is (patch for OOUI):
diff --git a/src/themes/wikimediaui/windows.less b/src/themes/wikimediaui/windows.less index 5e4d8c04..16428f22 100644 --- a/src/themes/wikimediaui/windows.less +++ b/src/themes/wikimediaui/windows.less @@ -291,6 +291,21 @@ .oo-ui-transform( scale( 1 ) ); } } + + &.oo-ui-window-ready { + > .oo-ui-window-frame:after { + // When iOS Safari address bar is collapsed, the viewport is resized, but it's not animated + // smoothly. For a brief moment during Safari's animation a part of the page "below" the + // viewport is visible. Put a small white rectangle there, so that the content underneath + // the dialog does not flash before we can resize it. + content: ''; + position: absolute; + top: 100%; + height: 200px; + width: 100%; + background: red; + } + } } &-modal&-floating > .oo-ui-dialog > .oo-ui-window-frame {
Unfortunately it does not work. Apparently Safari outsmarts us, realized that this element is outside of the viewport, and just does not render it.
Given this, I am not sure if we (Editing team) should work on this problem now. It seems rather trivial, and I'm not sure how we would go about fixing it. It might require some complex changes to the markup of OOUI dialogs.