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

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

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

Cannot reproduce either.

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.

Wow…

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

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.

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.

Any browser info would help.

In T92932#1728334, @Prtksxna wrote:

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.

In T92932#2129302, @bmansurov wrote:

Any browser info would help.

Happens on Chrome 49 on Mac OS 10.9.5 for sure.

In T92932#2137681, @Izno wrote:

In T92932#1728334, @Prtksxna wrote:

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.

@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
  • The Flying Doctors of East Africa
• 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)
  • https://en.wikipedia.org/wiki/Even_Dwarfs_Started_Small (revision 720971360)
• 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)

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.

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

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

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

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