The easiest way to reproduce it - turn on the Chrome Dev tools at the bottom of the page.
On RC page click in the Filter search area or in the active Filter area, the Filter menu will open up.
Note: the issue is present with Saved filters too:
Etonkovidova | |
Dec 12 2017, 7:49 PM |
F11853234: Screen Shot 2017-12-15 at 4.16.58 PM.png | |
Dec 16 2017, 12:35 AM |
F11852041: Screen Shot 2017-12-15 at 2.24.00 PM.png | |
Dec 15 2017, 10:38 PM |
F11852073: Screen Shot 2017-12-15 at 2.34.56 PM.png | |
Dec 15 2017, 10:38 PM |
F11848641: Capture d’écran_2017-12-15_18-23-42.png | |
Dec 15 2017, 5:24 PM |
F11794693: changes-limit-and-date-popup-auto-flip.png | |
Dec 12 2017, 10:08 PM |
F11794707: changes-limit-and-date-popup-no-auto-flip.png | |
Dec 12 2017, 10:08 PM |
F11794186: image.png | |
Dec 12 2017, 9:55 PM |
F11794131: image.png | |
Dec 12 2017, 9:54 PM |
The easiest way to reproduce it - turn on the Chrome Dev tools at the bottom of the page.
On RC page click in the Filter search area or in the active Filter area, the Filter menu will open up.
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | matmarex | T182711 Recent changes: Filter menu opens upwards | |||
Resolved | matmarex | T183069 Issues with OOUI menus/popups that open upwards being overlapped by things | |||
Resolved | Volker_E | T183195 Release OOUI v0.24.4 with some backported patches |
Related issue - T182602: Vector: Long dropdown menus (e.g. select namespace) overlapped by namespace tabs and personal menu when they open upwards caused by (lack of adaptation to changes from) T158934.
Can also happen with "Save current filter settings" (bookmark icon) and maybe more other things.
For the big filters menu, we probably want to make it always open downwards, since some other things depend on this (and we scroll to make the menu usably large). This can be forced by overriding #getVerticalAnchorEdge. (nevermind, that's wrong)
For everything else, we probably want to set an $overlay so that it appears on top of skin interface elements. I don't think opening upwards is a problem, when there's more space in that direction.
What I meant by "adaptation to changes" is using newly introduced autoFlip config option. But that option is available only for [[https://gerrit.wikimedia.org/r/#/c/385309/4/src/widgets/PopupWidget.js|PopupWidget]] and not for [[https://gerrit.wikimedia.org/r/#/c/385309/4/src/widgets/MenuSelectWidget.js|MenuSelectWidget]], which is what filter menu inherits.
There are multiple elements that could use new autoFlip option, to prevent opening above, but as @matmarex points out, we may want to keep such behavior, which can be really useful sometimes.
Besides "Saved filters" and "Save current filter settings" pointed out by @Etonkovidova and @matmarex, popup for choosing changes limit and date could also be displayed upwards. If not displayed upwards, we get scrollbar, as you can see from screenshots below. Both are screenshots from actual size of browser on my laptop, I haven't made browser window smaller to point the direction out.
Displayed above | Displayed below, with scrollbar |
---|---|
Change 397974 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/core@master] mw.rcfilters.ui.MenuSelectWidget: Always open this menu downwards
Change 397978 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/skins/Vector@master] Fix z-index for RCFilters' overlay
Actually, it seems that you set $overlay correctly everywhere, and the ugly overlapping seen in the screenshots posted by Elena and myself above is because the overlay itself is below the personal menu in z-index.
I think everythingg here is fixed with these two patches.
Change 397978 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Fix z-index for RCFilters' overlay
Change 397974 merged by jenkins-bot:
[mediawiki/core@master] mw.rcfilters.ui.MenuSelectWidget: Always open this menu downwards
Change 398391 had a related patch set uploaded (by Catrope; owner: Bartosz Dziewoński):
[mediawiki/core@wmf/1.31.0-wmf.12] mw.rcfilters.ui.MenuSelectWidget: Always open this menu downwards
Change 398392 had a related patch set uploaded (by Catrope; owner: Bartosz Dziewoński):
[mediawiki/core@wmf/1.31.0-wmf.11] mw.rcfilters.ui.MenuSelectWidget: Always open this menu downwards
Change 398391 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.12] mw.rcfilters.ui.MenuSelectWidget: Always open this menu downwards
Change 398392 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.11] mw.rcfilters.ui.MenuSelectWidget: Always open this menu downwards
Mentioned in SAL (#wikimedia-operations) [2017-12-15T00:44:13Z] <catrope@tin> Synchronized php-1.31.0-wmf.12/resources/src/mediawiki.rcfilters/ui/mw.rcfilters.ui.MenuSelectWidget.js: T182711 (duration: 00m 56s)
Apparently, it is not only for the filters: https://de.wikipedia.org/wiki/Spezial:LintErrors/multiline-html-table-in-list
Checked in testwiki (wmf.12)
(1) Filters drop down on RC/Watchlist pages always open down.
(2) Saved filters are still open up (and there are transparent overlapping with the top navigation links).
(3) Move page Namespace T182602: Vector: Long dropdown menus (e.g. select namespace) overlapped by namespace tabs and personal menu when they open upwards opens up
(4) (T182999: Namespace selection dropdown opens in the wrong direction, Special page tab overlaps) also is still happening.
Since the scope of this task was only about filters on RC/Watchlist, other issues may be addressed separately.
QA Recommendation: Product should weigh in
The main filter menu is a very particular case because it's very long and we've engineered some very particular behavior for it to account for that fact. So I'm glad it's fixed.
I don't have a problem with the Saved Filters menu and the Number of Edits menu going upwards per se; this can be useful in some circumstances. However:
What I do have a problem with is that this change from @matmarex seems to have caused problems in quite a few places. Am I incorrect in thinking that what we're seeing is widespread? It appears (to my uninformed eyes) that these problems are surfacing because menus that had always gone down now interact with elements they never interacted with before, and were never optimized to work with. We have the examples below, but do we have any reason to suppose that these are the only instances of this type of issue?
@matmarex, how do you propose to address this problem? If the problems are widespread, combing through the site to address each instance of this individually seems impractical; it's certainly not something we care to do. Are you willing to take this on? Is there a systematic solution? Do you want to simply back out your change? @Volker_E, is this an issue with this particular menu type?
@jmatazzoni I'm already working on a systematic solution, my set of patches on T182602 (pending review since Wednesday) resolves all of the issues caused by menus/popups opening upwards that I know of, except for this issue with RCFilters (which is fixed by the two patches I submitted here; only one of them was backported though, the one for the main filter menu) and T182907 in VisualEditor (on which I'll have to work separately, I did not look into it yet).
Unfortunately it appears I'm the only engineer actively working on OOUI, so getting reviews for such things is difficult.
I probably should have anticipated these issues with Vector. I tested this change with MediaWiki/Vector, but in the example I chose (Special:Block, T107036#3796820) the dropdown list was not long enough to overlap the namespace tabs.
(I'll file a "tracking" task for all these issues, so that we can group them up without making them all duplicates.)
To @matmarex comment, we're normally focussing on code reviews on a OOUI release base and it was decided two weeks ago that we're not doing releases for the rest of December. I have still time-sensitively merged https://gerrit.wikimedia.org/r/#/c/398193/ but the patch of the systematic solution https://gerrit.wikimedia.org/r/#/c/398195/ missed context at that time, therefore it needed more time.
All of the problems related to Special:RecentChanges (and Special:Watchlist) have been fixed here a few weeks ago already, and will be deployed with wmf.15 this week. Only one patch was backported to wmf.12 before the holiday break.
Issues with the dropdowns on other pages (e.g. Special:MovePage and Special:Block) have also all been fixed, but only today, and they will be part of wmf.16 (it was too many patches to backport). See T183069 for details.