Vector: Long dropdown menus (e.g. select namespace) overlapped by namespace tabs and personal menu when they open upwards
Closed, ResolvedPublic

Description

Long dropdown menus (e.g. select namespace) are overlapped by namespace tabs and personal menu when they open upwards. Most easily seen at https://en.wikipedia.org/wiki/Special:ActiveUsers:


Original bug report:
in "move page" ui in vector, the namespace combo-box opens either upward or downward, depending on screen height and scroll-position.
when it opens upwards, the items above the upper tab-bar (aka #mw-head ), are not clickable.
this issue was raised by users on hewiki unable to move pages from "draft" to "article" namespace.
see screenshot: https://commons.wikimedia.org/wiki/File%3AMovepage-issue.png

REPRODUCTION:

  1. log in to enwiki into account with "move" permissions. use vector skin
  2. click "move" under the "more" menu in upper toolbar
  3. in the special:movepage screen, click the namespace input line
  4. if the namespace list box opens downwards, close it and play with browser window height and scroll position, until it opens upwards (see screenshot)
  5. notice that the items in the list overlapping top toolbar ( #mw-head element), are not clickable.

peace.

Kipod created this task.Dec 11 2017, 4:33 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 11 2017, 4:33 PM
matmarex updated the task description. (Show Details)Dec 11 2017, 7:17 PM

That's silly and sounds annoying. I'll look into this.

(Opening upwards instead of always downwards is a new feature from T158934)

matmarex renamed this task from "Move page" select namespace list sometime dysfunctional to "Move page" select namespace list sometime dysfunctional (overlapped by namespace tabs when it opens upwards).Dec 11 2017, 7:24 PM

So, Vector is intentionally set up so that the page content can never overlap the interface elements, like the tabs, even when absolutely positioned (df10f03a7a28e1cefceb65bebf2e008870e39cb4). Unfortunately in this case the dropdown menu is part of the page content…

To work around this, we allow for an "overlay" to display the dropdown menu in (essentially, a separate "layer" shown on top of everything else on the page – https://www.mediawiki.org/wiki/OOjs_UI/Concepts#Overlays). But this has to be specified for each widget separately, which is mightily inconvenient. I can fix this one, but the same problem will keep popping up in other places.

(In this case it's extra inconvenient, because it's a dropdown generated from PHP, so we can't specify the overlay when generating it, only override it manually later.)

I'll have to think how to fix this in general…

Kipod added a comment.EditedDec 12 2017, 9:32 PM

@matmarex :
if i may make a suggestion: the drop-down (or drop-up in this case) knows how to adjust its height: for instance, if you scroll the page down such that the toolbar is outside the window (but the window size is such that the drop-down still drops up), the list will become shorter, to fit in the window.

what you want (i think) is to teach this mechanism to use the top of the content instead top of the window as the limit.

peace.

I'm not sure if that would always make sense. (If there was no other way to resolve the current problem, I would support that, but if we can make the menu appear on top of everything else, I think that's better.)

Perhaps you'd like that behavior, but no doubt someone else would complain that the menu doesn't take up as much space as it could.

Also, for example in this case (menu opening downwards), should we also limit its are to the content (roughly the light-blue-bordered area, I guess) and prevent it from overlapping the footer? Why are the links on top of the page "special" while those at the bottom are not?

How about the sidebar, should popups like this in RC filters be allowed to overlap it?

Even if we defined how this is supposed to work, it would probably be quite a bit of work to set up. We'd have to use both the "content" and the window to limit the dimensions (otherwise the menu would appear partially offscreen if you scrolled). And we'd have to define the "content" area for each skin separately.

Kipod added a comment.Dec 13 2017, 7:18 PM

I'm not sure if that would always make sense. (If there was no other way to resolve the current problem, I would support that, but if we can make the menu appear on top of everything else, I think that's better.)

sounds good to me. i suggested it under the assumption that what you describe is impossible/difficult, and what i suggested is simple/easy.
of course, i may be wrong on one or both of these assumptions....

peace.

Change 398195 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[oojs/ui@master] Introduce OO.ui.getDefaultOverlay

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

Change 398196 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[oojs/ui@master] Put menus/popups of infused widgets into the default overlay

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

Change 398198 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/core@master] OOjs UI: Fix font size for default overlay

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

Change 398199 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/skins/Vector@master] OOjs UI: Fix z-index and font size for default overlay

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

matmarex renamed this task from "Move page" select namespace list sometime dysfunctional (overlapped by namespace tabs when it opens upwards) to Vector: Long dropdown menus (e.g. select namespace) overlapped by namespace tabs and personal menu when they open upwards.Dec 16 2017, 9:59 PM
matmarex removed a project: OOUI.
matmarex updated the task description. (Show Details)
matmarex added a subscriber: Elitre.

It's the same cause (we allowed all kinds of menus and popups to open upwards), but it will probably need a separate fix.

Found one more glitch: cirrus search is incompatible with content translation contributions menu. Try to search something, and when the autocomplete opens, hover on contributions link.

@IKhitron Can you elaborate? It seems to work fine for me.

@IKhitron Can you elaborate? It seems to work fine for me.

Not the special page, the search box.

Oh, duh. Interesting.

I'll file a separate task, pretty sure this is unrelated.

I've been submitting patch to the subtask (T183069), but I underestimated how many changes will be needed. I'm almost done fixing it all though.

matmarex closed this task as Resolved.

This will be fixed in MediaWiki with wmf.16 (to be deployed next week).

Anomie added a subscriber: Anomie.Jan 12 2018, 3:17 PM

Change 398199 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/skins/Vector@master] OOjs UI: Fix z-index and font size for default overlay

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

It looks like Timeless will need a z-index fix too.

Change 398199 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/skins/Vector@master] OOjs UI: Fix z-index and font size for default overlay

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

It looks like Timeless will need a z-index fix too.

There's no tag for that here though?

Whoops, I didn't realize Timeless needed a followup.

I've made a bit of a mess with the tasks here. I ended up submitting all the patches on T183069 (the subtask). I'll put the Timeless patch there too (there was already a MonoBook one).