Page MenuHomePhabricator

Page version status popup doesn't auto-close when you move mouse away
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

chrome_Rip7xTggKu.gif (682×1 px, 98 KB)

What happens?:
The popup stays.

What should have happened instead?:
It should auto-close. (Alternatively, the popup should appear only on click.)

Why?

  1. I'm pretty sure that the majority of mouse moves over that text for an unregistered Wikipedia user are accidental. But they trigger a popup that obscures page content. And that popup doesn't go away when you just move the mouse further.
  2. Even if it weren't accidental, the user should be able to move their mouse freely without triggering the emergence of certain elements that they can't remove without additional actions. The page space should not feel like a minefield. This is just bad UI/UX. (And no, increasing the delay before showing the popup won't make much difference. Mouse moving is a light action, it shouldn't produce "heavy" effects.)

Event Timeline

I'm open to reverting my patch at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1070056, which removed the auto close, if there's consensus for it. But there's also some folks that want to move this Dialog in the other direction... no auto open or auto close at all. (T373769: Rework "Page version status" in FlaggedRevs to be unambiguous about its nature) So we should decide on what the path forward is.

Yes, we do something someone complains, we change it, someone else complains. It's all fine, we all have different viewpoints and priorities. But someone needs to make a final decision here :(

@stjn @Tacsipacsi @Msz2001 @Dogu @Ladsgroup @Johannnes89 can you all weigh in in this ticket if you have an opinion please? Let's decide in this ticket before I write code :)

My opinion is that the new popup is inaccessible and not semantically written and needs to be fixed. I’ve already explained it/how in T373769#10119135. Auto-close/auto-open wouldn’t be required (and isn’t required) if the new code wasn’t rife with problems.

The decision I'd like help with in this ticket is how the hover behavior for this popup should work right now.

Option 1 - Status quo - Auto-open on hover. No auto-close on loss of hover.
Option 2 - Status quo ante - Auto-open on hover. Auto-close on loss of hover.
Option 3 - No auto-open on hover. No auto-close on loss of hover.

If we can't agree on something as a group in this ticket, it is likely we'll stay at Option 1 due to decision paralysis.

Let's keep this ticket laser-focused on the hover behaviors if we can. The popup HTML can be architected in the other ticket.

With the current popup, seems like Option 2 is the only logical one (especially since there are no affordances on the status text to indicate that it can be opened on click).

I believe that it should work either as option 2 or option 3 - so either functionality of a popup or of a dialog, not a mix of those.

Personally I have no strong preference for either of them but I agree with @stjn that making this appear on click will require to change the indicator into a proper button (which I don't know how feasible would be). Therefore if we consider only changes to appearance and functionality of this dialog-popup I'd go with option 2. (In that case I think the appearance should be adapted to match popup and not dialog, as in T373769: Rework "Page version status" in FlaggedRevs to be unambiguous about its nature).

I agree that this should either be click-to-open and click-to-close, or hover to open, and close when the mouse moves away. I have a personal slight preference for the former, because it's quite easy to accidentally mouse over the Pending icon when navigating up to any of the links in the top corner of the page (e.g. Edit, history, Watchlist).

Change #1072591 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):

[mediawiki/extensions/FlaggedRevs@master] Revert "advanced.js: remove closing #mw-fr-revision-details using mouseout"

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

Change #1072591 merged by jenkins-bot:

[mediawiki/extensions/FlaggedRevs@master] Revert "advanced.js: remove closing #mw-fr-revision-details using mouseout"

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

Novem_Linguae claimed this task.

There is consensus against option 1, so I went ahead and chose option 2 for now, to get us off of option 1.

Is the new version really the "Status quo ante"? If I move the curser upwards to "Tools" the popup appears, it disappears if I move the curser down over the popup. However, if the curser's path does not cross the popup, it remains open, even if I click elsewhere on the page.

The issue remains: to access "Tools", I must carefully navigate the curser around the "Eye-Icon", or I need to ensure to move the curser over the popup again. This behavior might lead to some user frustration.

Do you propose that we should add an .on( 'click', closeDialog )?

Also, this popup has generated a high number of tickets (I think around 6? I just filed another one at T375231: ext-quick-survey-panel is showing up inside mw-fr-revision-details) and user complaints. Perhaps we should look into reverting to what it was before.

I am not an expert here, but the "mouse out detection" implemented in the "isMouseOutBubble" function in
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1072591/2/modules/ext.flaggedRevs.advanced/advanced.js#36
seems to miss several scenarios. For example, when the curser is moved to the area with "View history, [Star Symbol], Tools" under the Vector2022 skin, the popup does not close as expected. This explains the problem I described earlier.

I also want to express my support for Samwalton9-WMF's suggestion: I prefer a click-to-open and click-to-close approach (option 3).

Agree on change from onhover to onclick to open this, it is overly intrusive