Page MenuHomePhabricator

Hover card often gets stuck in "open" state
Closed, ResolvedPublic

Description

Linux, FF 36.0.1

Steps to reproduce: Unknown.

I was browsing my own (paltry) User:Contributions, and accidentally moused over an article name. To my surprise, the popup would not go away. I clicked everywhere on the page, etc, and the only way to destroy the popup was to reload the page.

See also: T105782: Update close mechanism to hover cards

Observed behavior on http://reading-web-staging.wmflabs.org/wiki/Category:Popups_corpus
Chrome/Firefox/Safari

  1. Hover on any card
  2. Click on article (do not open in new tab)
  3. Select "back"
  4. Hovercard still open

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Also experienced a stuck Hovercard a few times. Just now on mediawiki.org. I'll try to remember to check JS errors next time.

Quiddity triaged this task as High priority.Jun 30 2015, 10:31 PM

Has anyone seen this happening given this was last reported back in August?

Since my last comment it happened to me once, didn't remember to debug before I closed the tab, that was more than 3 month ago.

Hopefully we'll get a chance to look at this in next 2 weeks...

phuedx added a subscriber: phuedx.Oct 5 2015, 3:35 PM

I've been unable to reproduce this but I'll keep my eyes peeled…

Cannot reproduce either.

JanZerebecki closed this task as Resolved.Oct 7 2015, 11:18 AM
JanZerebecki claimed this task.

Unless it happens again to someone lets assume it was fixed.

This is going to sound like the worst steps to reproduce ever, but here goes: Open the Main_Page on en.wiki, quickly hover over a lot of links, sometime get your mouse on the hovercard and then jump to another link, while a hovercard is open switch to other tabs using keyboard shortcuts, come back to this tab, continue to switch between links, it should happen. Usually takes around 2 minutes.

JanZerebecki reopened this task as Open.Oct 15 2015, 5:21 PM
JanZerebecki removed JanZerebecki as the assignee of this task.
phuedx added a comment.EditedNov 2 2015, 10:00 AM

@Jdlrobson: This should be moved out of Done now that we have such… excellent… steps to reproduce.

Jdlrobson lowered the priority of this task from High to Normal.Nov 2 2015, 11:00 PM
Qgil removed a subscriber: Qgil.Jan 13 2016, 3:02 AM
Izno added a subscriber: Izno.Mar 16 2016, 12:23 PM

I still have this issue occur (using Fx 44.0.2), most often on the watchlist where there are multiple links in a small space to hover over (most recently with the past month or so). I'm having trouble reproducing it now, but I'll try to add some reproducing steps here when I bump into it next.

Krinkle renamed this task from Article name hover popup sometimes gets stuck open to Hover card often gets stuck in "open" state.Mar 17 2016, 12:03 AM

When just reading an article and hovering a link here and there, quite often it eventually gets stuck. Sometimes even on the first attempt on a page.

It's not related to state getting messy after prolonged use. Sometimes the first link I hover makes it go stuck, sometimes it takes longer. It seems to relate to an unstable event model being used. A race between the mouse enter and mouse leave or some such.

Krinkle raised the priority of this task from Normal to High.Mar 17 2016, 12:05 AM

Any browser info would help.

Izno added a comment.Mar 20 2016, 1:46 PM

This is going to sound like the worst steps to reproduce ever, but here goes: Open the Main_Page on en.wiki, quickly hover over a lot of links, sometime get your mouse on the hovercard and then jump to another link, while a hovercard is open switch to other tabs using keyboard shortcuts, come back to this tab, continue to switch between links, it should happen. Usually takes around 2 minutes.

This is basically what I got to happen at this template revision; the Famicom Modem link is a redirect and is the link in question which caused me grief. (I don't think the fact it's a redirect is important, but might as well mention it).

I eventually got it to clear by subsequently hovering over the link multiple times. The only information in console is Expected 'none' or URL but found '.'. Error in parsing value for 'clip-path'. Declaration dropped., from index.php. I don't know if it's related.

Any browser info would help.

Happens on Chrome 49 on Mac OS 10.9.5 for sure.

Jdlrobson lowered the priority of this task from High to Normal.Apr 20 2016, 8:56 PM

I've spent the last 30 mins trying to make sense of this myself with no luck.
Something that cannot be replicated reliably and is not in production cannot be justified as high (it's blocking the roll out).
Is it possible a gadget might be interfering?

Next time it happens, can someone report with the following:

  • Link that led to Hovercard being stuck
  • How the hover occurred (was it due to a mouse hover or pressing tab button or accidental/unintentional hover)
  • Page, revision and wiki being viewed (preferably url to that revision)
  • Browser being used and Operating system
  • Whether user has any gadgets installed. If so what?

I'm hoping the refactoring and test writing we are doing right now will iron out what this problem is and eradicate it.

This is going to sound like the worst steps to reproduce ever, but here goes: Open the Main_Page on en.wiki, quickly hover over a lot of links, sometime get your mouse on the hovercard and then jump to another link, while a hovercard is open switch to other tabs using keyboard shortcuts, come back to this tab, continue to switch between links, it should happen. Usually takes around 2 minutes.

This is basically what I got to happen at this template revision; the Famicom Modem link is a redirect and is the link in question which caused me grief. (I don't think the fact it's a redirect is important, but might as well mention it).

Same here.

The only information in console is Error in parsing value for 'clip-path'. Declaration dropped.. I don't know if it's related.

It is not related. It relates to internal Firefox processing of the CSS.

He7d3r added a subscriber: He7d3r.May 17 2016, 5:29 PM
kaldari added a subscriber: kaldari.EditedJul 18 2016, 1:09 AM

@Jdlrobson, @phuedx: Here is a video of the bug happening (today on en.wiki). The bug was already triggered at the beginning of the video, but is triggered again at 6 seconds into the video. There are no console errors and no new ajax requests. It seems to be a timing bug. It is never consistently reproducible for me. This bug seems to occur more frequently when I have a slow internet connection, but I don't have any objective evidence to base that on.

Answers to questions:

  • Link that led to Hovercard being stuck
  • How the hover occurred (was it due to a mouse hover or pressing tab button or accidental/unintentional hover)
    • intentional mouse hover
  • Page, revision and wiki being viewed (preferably url to that revision)
  • Browser being used and Operating system
    • Firefox 47.0 with Adblock Plus, MacOS 10.10.5
  • Whether user has any gadgets installed. If so what?
    • Logged in with lots of gadgets including Twinkle, HotCat, UTC Clock, BugStatusUpdate, etc., but not Navigation Popups.

Next time this happens can you grab me to debug it live? I can't replicate it on Firefox 47 so my guess would be it is connection specific/AdBlock related or gadget related.

(thanks for such a detailed bug report)

Krinkle removed a subscriber: Krinkle.Sep 2 2016, 12:19 AM

Sidenote: A user suggests (in https://www.mediawiki.org/wiki/Topic:Tb42ves6zs2v7nda):

A possible solution to this (and concerns others have had about their placement) might be to give them a "handle" that can be grabbed and dragged, along with an "x" (close) button that can be used to close a particular hovercard, if desired.

I've noted that an "x" (close) button was declined in T105782, but I thought the "handle" idea worth passing along.

@kaldari replicated this and allowed me his laptop to debug.
What I noticed:

  • The element .mwe-popups had .mwe-popups-fade-in-down .flipped_y and .mwe-popups-is-not-tall classes.
  • The element had styles top, left and display block inline styles

When this doesn't get stuck it doesn't have .mwe-popups-fade-in-down and it is display none. I also have a mwe-popups-image-tri class.

Ignoring the absence popups-image-tri for a minute the existence of the .mwe-popups-fade-in-down class is revealing.
The only place we hide the popup is in this code block:

		mw.popups.render.wait( 150 ).done( function () {
			if ( mw.popups.$popup.hasClass( fadeOutClass ) ) {
				mw.popups.$popup
					.attr( 'aria-hidden', 'true' )
					.hide()
					.removeClass( 'mwe-popups-fade-out-down' );
			}
		} );

As you can see the popup will only be hidden if it has the fadeOutClass.
What is fadeOut class? Let's look at the logic:

		fadeOutClass = ( fadeInClass === 'mwe-popups-fade-in-up' ) ?
			'mwe-popups-fade-out-down' :
			'mwe-popups-fade-out-up';

So this will be mwe-popups-fade-out-down or mwe-popups-fade-out-up. We don't have either - we have the class mwe-popups-fade-in-down

The method closePopup is supposed to remove the mwe-popups-fade-in-down class and then add the fade out class and then set a timer to remove it. This means that closePopup is not running in this circumstance. Why?

closePopup will be called if

  • closeOnEsc is invoked (the escape key is pressed)
  • leaveActive is invoked and getActiveLink returns something

leaveActive looks the most suspicious.

  • It uses a timeout which it binds to closeTimer (it can thus be aborted).
  • If setActiveLink is called with null before the wait finishes
    • which can happen if mw.popups.render.reset is called
    • mw.popups.render.reset is called in the leaveInactive event.

closeTimer can be aborted inside several places:

  • a call to closePopup (which we've already established is not happening)
  • render (when its invoked again for the same popup card)
  • a mouseenter event on the hovercard.

There is a lot of confusing logic here. Some combination of these events is probably aborting the closeTimer.
The only way imo we can fix this is simplifying all this logic with a rewrite.

I experienced this bug again today and was able to confirm that it affects both "up" and "down" pop-ups, i.e. the pop-up that won't close was a "down" pop-up and had the class "mwe-popups-fade-in-up" in it's stuck state.

Okay I can replicate this now. Probably what is happening to the bug reporters is something similar.

  • Resize your browser window so that you can move your mouse outside the browser window.
  • Tab towards a link that will display a hovercard... don't tab to link just yet.
  • Tab and move your mouse cursor outside the browser window. If you do this quickly enough you will now be in the stuck state.


I should point out clicking the page however does make this hovercard go away as it steals the focus. I'm not sure if that is consistent with the original @awight experience which may be outdated but it seems to be the same one @kaldari was having.

This is somewhat related to T142723 so I hope a fix there will also fix this.

kaldari added a comment.EditedNov 17 2016, 7:17 PM

@Jdlrobson: I still experience both versions of this bug: the hovercard being open when it shouldn't be, and the hovercard being completely stuck and not possible to close. I haven't figured out a way to reproduce the 2nd version, although it happens about once a week.

ovasileva raised the priority of this task from Normal to High.Dec 2 2016, 2:44 PM
ovasileva updated the task description. (Show Details)Dec 2 2016, 2:53 PM
ovasileva moved this task from 2014-15 Q4 to Triaged but Future on the Readers-Web-Backlog board.
ovasileva moved this task from 2016-17-Q2-Goal to Done on the Page-Previews board.Dec 19 2016, 7:22 PM
ovasileva moved this task to For Review on the Page-Previews board.

Hi, this is my first time on Phabricator. I'm adding my experience with this bug; namely, an image of the bug

where my cursor (not sure if it appears in the image) is located all the way to the left side. I posted this text at the MediaWiki discussion page for hovercards.

when I mouse over a hovercard, it pops up, I read it, I move my mouse away, and the card doesn't go away. I can sometimes get rid of it by remousing over that wikilink or another link, but more often than not, the card will momentarily disappear and then reappear. Sometimes I can scroll up or down to get rid of it. My OS is the ChromeOS on a Toshiba Chromebook. Here's the system info:
Version 56.0.2924.58 beta (64-bit)

Platform 9000.58.0 (Official Build) beta-channel swanky

Firmware Google_Swanky.5216.238.5)

Let me know if this helps at all with reproducibility. Thanks, Icebob99

@Icebob99 I appreciate you taking the time to share your experience. If you have a moment, can you see if you have the same problem at the following page? There's some improvements (that's actually a bit of an understatement) to the code that has yet to reach production, but is available on the staging wiki. :)

http://reading-web-staging.wmflabs.org/wiki/Category:Popups_corpus

jeblad added a subscriber: jeblad.Jan 24 2017, 12:12 PM
ovasileva closed this task as Resolved.Feb 15 2017, 11:08 AM
ovasileva claimed this task.
ovasileva added a subscriber: ovasileva.

Tested: Safari 9.1.3

  1. Go to article for dog
  2. Hover over "carnivorous"
  3. Cntl + click on "carnivorous"
    1. Carnivorous page opens
  4. Close Page
    1. Preview appears open
    2. Preview closes

Observed behavior is acceptable. Resolving.

kaldari reopened this task as Open.Feb 16 2017, 4:09 PM

Ran into this bug again today on English Wikipedia with Firefox. Below is the HTML of the hovercard while it was stuck. Moving the cursor into and out of the card had no effect. Clicking the page outside the card had no effect. The only way to get it to go away was to open another hovercard.

<div class="mwe-popups mwe-popups-fade-in-down flipped_x_y mwe-popups-is-not-tall" role="tooltip" aria-hidden="false" style="top: 3806.52px; left: 521.567px; display: block;"><div>

I'm assuming that the new refactored code isn't live on English Wikipedia yet. Is that correct?

Jdlrobson closed this task as Resolved.Feb 16 2017, 4:15 PM

Correct, it's not live yet. This is the old code.
The new code is riding the train and will be on English Wikipedia on 23rd. If you hit the bug after then, I'll be very surprised but please do reopen!