| Isarra | |
| Aug 24 2019, 2:05 PM |
| F30089395: image.png | |
| Aug 24 2019, 2:09 PM |
None of this impedes usage, but looks anything from not particularly noticeable to outright dubious depending on what theme is active. Because the scrollbar just vanishes, leaving behind whatever background is behind all of the content, it can be quite the contrast.
Timeless desktop-small issues are largely a timeless problem, but also indicate some other side effects that are possible from this approach.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Update OOUI to v0.48.3 | mediawiki/core | master | +1 K -1 K | |
| WindowManager: Fix faking scrollbar width on the wrong side in RTL | oojs/ui | master | +13 -14 |
The scrollbar thing is intentional/unavoidable – when a OOUI dialog opens, we disable the scrolling of the page using overflow: hidden; (by adding the .oo-ui-windowManager-modal-active class to <body>), and doing that also removes the scrollbar.
When doing so, we also set margin-right on the <body> equal to the width of the scrollbar, and position: relative; (via the CSS class), so that the content of the page doesn't shift. However, this doesn't seem to work well for Timeless (maybe because menus are absolutely positioned). And this is what is causing the header mess, the position: relative; apparently breaks some positioning.
The scrollbar thing also looks quite strange in MonoBook and Vector, just doesn't stand out as much.
Is there any particular reason you can't just disable scrolling outside of the active dialogue window while the overlay is active? As in, disable the effects of actions that would move around on the content, instead of changing how the content itself is.
I don't think there is a reliable way to prevent scrolling without getting rid of the scrollbar. The 'scroll' event is not preventable. You could prevent events for things that cause scrolling: keyboard arrow keys, mouse wheel, touch and pan (this would be very tedious), but ultimately on desktop you can scroll by clicking on the scrollbar and AFAIK there is no way to prevent that. The best you can do is scroll back to the previous position afterwards, which in my opinion is absolutely awful to experience as a user.
Change 966299 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[oojs/ui@master] WindowManager: Fix faking scrollbar width on the wrong side in RTL
Test wiki created on Patch demo by Matma Rex using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/50dc373669/w
Also created an OOUI Demos page:
https://patchdemo.wmflabs.org/wikis/50dc373669/w/build/ooui/demos
We can now avoid messing up the various styles, using a new CSS property that was introduced since my last comment here in 2019. I'm afraid we still can't avoid removing the scrollbar, though. I think we should close this task after this change is merged.
Change 966299 merged by jenkins-bot:
[oojs/ui@master] WindowManager: Fix faking scrollbar width on the wrong side in RTL
Test wiki on Patch demo by Matma Rex using patch(es) linked to this task was deleted:
Change 980958 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):
[mediawiki/core@master] Update OOUI to v0.48.3