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

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

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…

@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.

In T182602#3832647, @matmarex wrote:

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

This seems to be related to T182907: Link inspector overlapped by toolbar and extends past the screen when it opens upwards (only when editing links in tables and references).

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.

In T182602#3863784, @matmarex wrote:

@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.

In T182602#3836364, @gerritbot wrote:

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.

In T182602#3896889, @Anomie wrote:

In T182602#3836364, @gerritbot wrote:

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).