Page MenuHomePhabricator

Recent changes: Filter menu opens upwards
Closed, ResolvedPublic

Description

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.

image.png (516×1 px, 124 KB)


Note: the issue is present with Saved filters too:
Screen Shot 2017-12-12 at 1.38.59 PM.png (415×808 px, 82 KB)

Event Timeline

Can also happen with "Save current filter settings" (bookmark icon) and maybe more other things.

image.png (516×1 px, 119 KB)

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 aboveDisplayed below, with scrollbar
changes-limit-and-date-popup-auto-flip.png (745×1 px, 112 KB)
changes-limit-and-date-popup-no-auto-flip.png (677×1 px, 77 KB)

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

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

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

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

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

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

jmatazzoni renamed this task from Recent changes: Filter menu opens up to Recent changes: Filter menu opens upwards.Dec 13 2017, 4:39 PM

Change 397974 merged by jenkins-bot:
[mediawiki/core@master] mw.rcfilters.ui.MenuSelectWidget: Always open this menu downwards

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

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

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

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

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

Change 398391 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.12] mw.rcfilters.ui.MenuSelectWidget: Always open this menu downwards

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

Change 398392 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.11] mw.rcfilters.ui.MenuSelectWidget: Always open this menu downwards

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

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)

Are T182999 and/or T182907 duplicates, then?

I'll check them as a separate cases when will be checking the fix.

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

Screen Shot 2017-12-15 at 2.24.00 PM.png (333×389 px, 35 KB)

(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

Screen Shot 2017-12-15 at 2.34.56 PM.png (461×687 px, 109 KB)

(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

jmatazzoni added subscribers: Volker_E, Pginer-WMF.

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:

  • The interaction between Saved Filters and the top menu has to be fixed one way or another (I don't care how).
  • And I will defer to @Pginer-WMF, if he sees an issue here in general and would like to reinstate the downward behavior of all the menus.

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?

Screen Shot 2017-12-15 at 2.24.00 PM.png (333×389 px, 35 KB)
Screen Shot 2017-12-15 at 2.34.56 PM.png (461×687 px, 109 KB)
Screen Shot 2017-12-15 at 4.16.58 PM.png (612×847 px, 65 KB)

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