Page MenuHomePhabricator

Fix Special:RecentChanges dropdown widget on mobile
Closed, ResolvedPublic8 Estimated Story Points

Description

In order to enable the Special:RecentChanges page on mobile, the advanced filters on that page have to be adequately functional. After investigating various solutions to this end in T224655 it was deemed that the filters are mostly functional, except for the filter dropdown (i.e. the "menuSelectWidget" in rc-filter parlance).

This task encompasses just the changes need to make that widget functional on mobile.

This does not include changes that effect the layout or visual correctness of the widget, but just its functionality.

The widget is broken in three ways.

  1. The dropdown options disappear on small screens.
    rcfilters-clipping-mobile.gif (426×240 px, 1 MB)
  2. The virtual keyboard appears when you tap the "filter changes" input as well as every time you check a checkbox in the dropdown. On mobile, this selection process can function adequately without the keyboard at all.
    rcfilters-keyboard.gif (426×240 px, 696 KB)
  3. When tags are added to the tag-list above the dropdown, the dropdown is misplaced, only to be corrected after a scroll event fires. This correction should occur when a tag selection happens.
    rcfilters-scroll-shift.gif (426×240 px, 456 KB)

Developer notes

  1. Invisible options - It's been found that adding width: 100% to this menuSelectWidget CSS rule can fix the "disappearing options" issue:
.mw-rcfilters-ui-menuSelectWidget-body {
    max-height: 70vh;
    min-width: 100%;
}
  1. Virtual keyboard - In FilterTagMenuSelectWidget.js The text input seems to explicitly gain focus in the onMenuToggle method on line#341, and regain focus through the onMenuChoose method on line#283. We could wrap these focus calls in some sort of "isMobile" conditional, or add a "readonly" attribute to this input on mobile (unless someone has a better idea).
FilterTagMultiselectWidget.prototype.onMenuToggle = function ( isVisible ) {
	// Parent
	FilterTagMultiselectWidget.parent.prototype.onMenuToggle.call( this );

	if ( isVisible ) {
		👉this.focus();
...

FilterTagMultiselectWidget.prototype.onMenuChoose = function ( item ) {
	this.controller.toggleFilterSelect( item.model.getName() );

	// Select the tag if it exists, or reset selection otherwise
	this.selectTag( this.findItemFromData( item.model.getName() ) );
	👉 this.focus();
};
  1. Positioning after change - on line#273 of FilterTagMultiSelectWidget.js the updateIfHeightChanged method is overridden with a no-op. If this override is removed, the dropdown positions itself correctly when the tags are selected.
/**
 * Override parent method to avoid unnecessary resize events.
 */
FilterTagMultiselectWidget.prototype.updateIfHeightChanged = function () { };

QA steps

Environment: beta cluster, Special:RecentChanges page https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:RecentChanges
mobile mode: AMC
user permissions: logged in

The goal is to ensure the filter menu (i.e. the popup menu that appears when clicking the "filter" input) works "correctly" on mobile devices. Testing on real device, both iOS and Android is preferred, since this involves checking the behaviour of the onscreen keyboard. The filter menu should meet the AC below.

Acceptance Criteria

  • The filter menu doesn't disappear on mobile devices unexpectedly, or when scrolling through it.
  • The filter menu closes when clicking the "x" icon on the filter input.
  • The virtual keyboard does not appear when the filter menu appears.
  • The virtual keyboard does not appear when checking an option in the filter menu.
  • Checking an option in the filter menu adds it to the "active filters" area.
  • The dropdown positions itself correctly below the "Filters" input when more than one row of tags is added.

Event Timeline

ovasileva moved this task from Incoming to Upcoming on the Web-Team-Backlog board.

Change 516607 had a related patch set uploaded (by Jdrewniak; owner: Jdrewniak):
[mediawiki/core@master] Set min-width on rcfilter dropdown

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

Change 516610 had a related patch set uploaded (by Jdrewniak; owner: Jdrewniak):
[mediawiki/core@master] Removes updateIfHeightChanged override on rcfilters

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

Issue 1 looks similar to T180173: PopupWidget is not correctly clipped with left/right edge (other ClippableElements work fine).

ClippableElement expects the container to adjust to the dimensions of the clippable, but since it has an explicit width it doesn't, and all hell breaks loose.

You can see in the GIF that the wrapper around the list of filters has a minimum width set, that is larger than the screen width, which ultimately causes this issue.

Change 516610 merged by jenkins-bot:
[mediawiki/core@master] Removes updateIfHeightChanged override on rcfilters

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

Change 516607 merged by jenkins-bot:
[mediawiki/core@master] Set min-width on rcfilter dropdown

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

@matmarex thanks for the insight. I see it's a tricky issue because a fixed or min width is sometimes desirable. What I did to work around this issue in this case is set a max-width:100% on the container element, which offsets the min-width value.

Change 517026 had a related patch set uploaded (by Jdrewniak; owner: Jdrewniak):
[mediawiki/core@master] Adapt Recent Changes advanced filters for mobile usage

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

👆Regarding the above patch, it fixes the virtual keyboard issue on the advanced filters form, but it does so in an unconventional way, so I'll explain.
First it uses the OO.ui.isMobile to check if a user is on a mobile device. I believe that method only returns true if mobileFrontend is used, so using Minerva as a desktop skin isn't affected. If isMobile returns true, a readonly attribute is placed on the search input.

This readonly attribute prevents the virtual keyboard from being shown on mobile devices, but it still reveals the dropdown. This essentially turns the search input into a button. The reason the search input can't be turned into an actual button widget, is that the rest of the logic expect $input related values to be present, and not button related ones. Making the code accept both would lead to a lot of different code paths and would make the code more error-prone.

I think this readonly approach is still semantically correct, although it's somewhat unintuitive.

@ovasileva @alexhollender one other thing this patch does, is enable the rcfilters module on mobile.
This means that instead of seeing the current page, users will get the still-unperfect-but-somewhat-useable version of the advanced filters:

Screen Shot 2019-06-17 at 17.43.39.png (1×1 px, 864 KB)

(before | after)
The patch is up on staging in case there are any objections to this change (IMO I think it's still think it's better than the what we have currently) and it's up on staging currently:

http://reading-web-staging.wmflabs.org/wiki/Special:RecentChanges?hidebots=1&translations=filter&limit=50&days=30&enhanced=1&urlversion=2

I did this to facilitate testing, because it's hard to fake the isMobile condition used to modify the keyboard behaviour. It can be set via custom header, but this way it can be tested easily by clicking "mobile mode" or going to an m-dot domain instead.

@Jdrewniak awesome progress. Just checked this out on iOS and Android. The two main things that seem worth improving:

1) the height of the filter menu

  • on iOS it seems to grow based on available space. If you open the menu when the button is towards the bottom of the screen the menu ends up being very short. I wonder if giving a max height, or somehow scrolling the page once the menu is triggered, would result in a taller menu.
    IMG_716E3494F43D-1.jpeg (1×750 px, 343 KB)
  • on Android the menu is short regardless of scroll position
    Screenshot_20190617-204058.png (2×1 px, 191 KB)

2) the ability to close the filter menu

  • not sure what we can do about this aside from constraining the width of the menu so that you can tap out of it on either the right or left side. Any ideas?
  • on iOS the bottom of the keyboard appears, including a "Done" button. I don't think it's a big deal though it did at first make me think that if I hit "Done" the filter menu would close.
    IMG_2791.PNG (1×750 px, 112 KB)

Of smaller concern is how to communicate more clearly what's happening when you tap either "Namespaces" or "Tags". Currently the blue border on "Basic filters" remains active. Our audience is people who already know their way around this filter menu, so I don't think it's very important. Also if you tap "Done" on the iOS keyboard when you're on the tags tab the input gets a red border:

IMG_2794.PNG (1×750 px, 129 KB)

@alexhollender thanks for the feedback!

menu height

I wonder if giving a max height, or somehow scrolling the page once the menu is triggered, would result in a taller menu.

The page does scroll down a bit when you activate the menu, but it's only to the top of the of the "active filters" box, not to the top of the search input.

Just as an observation, it seems like the menu is at it's smallest when there are no results. The "no results" message is given a 5em top/bottom margin, which give the page some height and some room for the menu to expand. I can try to play around with that value to make it larger on mobile (maybe using a vh value instead) so that the menu has more available space.

One thing I did do to increase the space is I removed the "tell us what you think" message from the footer for mobile, this should give the menu a bit more room.

on Android the menu is short regardless of scroll position

Hopefully this is fixed in the latest patch, I updates staging, so let me know if this is still an issue.
http://reading-web-staging.wmflabs.org/wiki/Special:RecentChanges?hidebots=1&translations=filter&limit=50&days=30&enhanced=1&urlversion=2

menu closing
I'm still trying to think of something that would make closing this menu obvious on mobile.
I'm trying to stick a close button somewhere, but I haven't gotten this working yet.

Screen Shot 2019-06-18 at 14.57.23.png (1×950 px, 149 KB)

on Android the menu is short regardless of scroll position

Hopefully this is fixed in the latest patch, I updates staging, so let me know if this is still an issue.
http://reading-web-staging.wmflabs.org/wiki/Special:RecentChanges?hidebots=1&translations=filter&limit=50&days=30&enhanced=1&urlversion=2

@Jdrewniak that seems to have done the trick. The height behavior isn't entirely consistent but often it seems like it doesn't take up the entire available space, e.g.

Screenshot_20190618-211647.png (2×1 px, 267 KB)

@alexhollender the latest update takes into account a few more of your concerns.
I removed the blue border around the input when the dropdown is open, and I added an "x" icon on the popup menu so that it's easier to close.
The scrolling behaviour is also modified so that the page scrolls to the top of the search input (most of the time) when the menu is opened.

I've also started modifying the layout of the "namespaces" and "tags" buttons to be more mobile friendly.

https://reading-web-staging.wmflabs.org/w/index.php?hidebots=1&limit=500&days=30&enhanced=1&title=Special:RecentChanges&urlversion=2&mobileaction=toggle_view_mobile

phuedx moved this task from Triaged to MinervaNeue on the Mobile board.

@Jdrewniak wow, looking awesome. I thought of how we might simplify it further, though unless it'd be relatively easy to do I don't know that it's worth investing more time here since it's working fine already.

image.png (1×1 px, 306 KB)

Change 517026 merged by jenkins-bot:
[mediawiki/core@master] Adapt Recent Changes advanced filters for mobile usage

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

This comment was removed by ovasileva.
QA on iOS

Environment: beta cluster, Special:RecentChanges page https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:RecentChanges
mobile mode: AMC
user permissions: logged in

  • noting that the recent changes page appears like this regardless of whether you're in AMC or not, which is expected

The goal is to ensure the filter menu (i.e. the popup menu that appears when clicking the "filter" input) works "correctly" on mobile devices. Testing on real device, both iOS and Android is preferred, since this involves checking the behaviour of the onscreen keyboard. The filter menu should meet the AC below.

Acceptance Criteria
  • The filter menu doesn't disappear on mobile devices unexpectedly, or when scrolling through it.
  • The filter menu closes when clicking the "x" icon on the filter input.
  • The virtual keyboard does not appear when the filter menu appears.
  • The virtual keyboard does not appear when checking an option in the filter menu.
  • Checking an option in the filter menu adds it to the "active filters" area.
  • The dropdown positions itself correctly below the "Filters" input when more than one row of tags is added.
Notes
  • page/live updates loads VERY slowly - not a blocker and I'm assuming that's just the beta cluster
QA on android

I checked this on Android / Samsung Galaxy / Chrome. Confirming that the following acceptance criteria are met:

  • The filter menu doesn't disappear on mobile devices unexpectedly, or when scrolling through it.
  • The filter menu closes when clicking the "x" icon on the filter input.
  • The virtual keyboard does not appear when the filter menu appears.
  • The virtual keyboard does not appear when checking an option in the filter menu.
  • Checking an option in the filter menu adds it to the "active filters" area.
  • The dropdown positions itself correctly below the "Filters" input when more than one row of tags is added.
ovasileva claimed this task.

Looks good everywhere, resolving