Page MenuHomePhabricator

Jarring scrolling bug in dropdown panel for RC Page filters
Closed, ResolvedPublic

Description

On a Mac using Chrome, do the following:

  1. Make sure you are on a version of beta Recent Changes with plenty of results (because vertical scrolling is required).
  2. Click the Active Filter Area to open the RC Page dropdown filter panel.
  3. Place your cursor as a user typically might, in the middle of the dropdown panel.
  4. Use a scroll wheel or double-finger touchpad touch to scroll the dropdown panel.

Result: when the scroll controls at right of the panel show that you've scrolled to the bottom of the panel, the page itself starts scrolling, BUT the cursor does not move relative to the page or the panel. It stays in the center of the panel. At some point—presumably when the page thinks the cursor has moved off the panel—the panel suddenly and jarringly closes.

Expected result: The thing that makes this jarring is that, from the user's POV, the cursor is still on the panel, yet the panel suddenly closes. IMHO that is a bad bug. I'm not 100% sure what should happen: whether the page should NOT scroll when you hit the bottom of the panel (and you would just stop?), or whether the page should scroll but the cursor should move down, as it normally would when the page scrolls. Either would be fine, I think. The key is that the panel shouldn't close while the cursor is still visually hovering on it.

@Mooeypoo says this is probably related to OOUI, and that it happens only on a Mac. @Pginer-WMF, what is the desired behavior? @Volker_E, is this something in OOUI?

Details

Event Timeline

The short explanation is, that the calling element for the dropdown, the search input field is getting scrolled out of the viewport. Therefore the humongous dropdown menu (that will cause other issues on smaller viewports) is hidden.

We might be able to solve this by adding max-height to the popup, so you never get to scrolls away from the input.

(Also, correction -- It doesn't only happen on a Mac, but it tends to have worse scrolling issues on a mac because of the way the default "don't display a scrollbar" behavior is on a mac)

We might be able to solve this by adding max-height to the popup, so you never get to scrolls away from the input.

Don't forget that the popup is Clippable, and Clippable sets a max-height on things, so that might be a problem.

(Also Pau wants max-height: 70vh or similar on the popup anyway for other reasons.)

Pginer-WMF added a comment.EditedFeb 15 2017, 10:18 AM

@Pginer-WMF, what is the desired behavior?

The desired behaviour is for the panel not to suddenly disappear.

There are two aspects that are missing int he current implementation (you can try both of them in the prototype):

  • The panel should not occupy the whole viewport vertically. I suggested setting the height based on the viewport height, as Roan mentioned. More details in T149452#2981306
  • The page should scroll to maximise the available viewport for the filters when needed. If there are elements visible on top of the filter area, the page scrolls as soon as the search bar gets focused. Note in the prototype that the page never scrolls up, only scrolls down. Note also that it only scrolls down when there are a significant amount of pixels to scroll down, avoiding moving for just few pixels. There are more details about this in T149435, and an animation in F4687875

(to check later if some other fixes will fix the issue below)
An interesting ramification of the issue described in this ticket will be that the highlight color box will get de-attached with scrolling.

Use case: You decide to highlight Logged actions. Logged actions filter is placed at the bottom of the filter selection list.

  1. Open the filter selection drop-down list and scroll down to the 'Logged actions' which is at the bottom of the list. Click to open the highlight colors selection.
  2. The highlight selector box will not be fully open. The page will not scroll to accommodate the display of the highlight color popup

  1. When the page is forcefully scrolled - the highlight color popup will get de-attached:

Change 339736 had a related patch set uploaded (by Mooeypoo):
RCFilters UI: Limit filter popup height

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

Change 339736 merged by jenkins-bot:
RCFilters UI: Limit filter popup height

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

This is a FloatableElement feature. It's intended to prevent weird "disconnected" menus from appearing onscreen, e.g. with DropdownWidget and the like.

For example, here's how the "DropdownInputWidget (long)‎" example from https://doc.wikimedia.org/oojs-ui/master/demos/ would look like without this. After the dropdown "handle" is scrolled offscreen, nearly the entire page is covered with a menu that doesn't appear connected to anything.

If this behavior would be okay for your interface, I can suggest two workarounds:

  • Add an override for #isElementInViewport on your widget that just returns true. FloatableElement will think that the handle is always onscreen, and never hide itself. (If anyone asks, I did not tell you this, that method is private and you override it on your own risk.)
  • Prevent the user from scrolling the page while the menu is open.

Change 341101 had a related patch set uploaded (by wikigit):
[mediawiki/core] RCFilters UI: Prevent the popup from disappearing when input is out of view

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

Change 341101 merged by jenkins-bot:
[mediawiki/core] RCFilters UI: Prevent the popup from disappearing when input is out of view

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

Checked in betalabs

  • the jarring scrolling issue is fixed - the open drop-down will never be out of view when scrolling
  • the detached highlight color selection box issue is not present anymore

QA recommendation: Resolve.

jmatazzoni closed this task as Resolved.Mar 9 2017, 12:00 AM
jmatazzoni claimed this task.