Things I'm a little concerned about that we should think about while testing:
Would it be jarring to hide a hovercard when you click a link? Would it lead a user to think that they misclicked? If the connection is slow might this give the sense that nothing is happened? Will Safari respect this or does the back button work differently?

Change 311596 had a related patch set uploaded (by Jdlrobson):
Clicking a Hovercards legible link should close popup

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

@bmansurov raised a question on the ticket @ovasileva which I feel is a product decision:
If a user hovers over a hovercard, clicks and holds a link, upon releasing the link should the hovercard still be shown?

Actually, you can ignore that question - if you change your mind about a link and release it you also have to move the mouse away from the link in which case we already hide the popup.

@ovasileva a little correction to the above scenario:

1. User hovers over a link and presses the mouse button (doesn't release it)
2. Since the user hovered over the link, a popup shows. The user then, without releasing the mouse button, moves the mouse pointer to over the newly opened Hovercard and then releases the mouse button.
3. Since the mouse cursor is still over the popup, as a user I expect the popup not to disappear. The reasoning is that, on the web when you click and drag away from the link without releasing the mouse button, your click isn't considered complete, thus you won't navigate away from the page.

In T143051#2650728, @Jdlrobson wrote:

Actually, you can ignore that question - if you change your mind about a link and release it you also have to move the mouse away from the link in which case we already hide the popup.

True, but what happens when you release it when you're over the Hovercard? In that case I don't expect the popup to disappear.

1. User hovers over a link and presses the mouse button (doesn't release it)
2. Since the user hovered over the link, a popup shows. The user then, without releasing the mouse button, moves the mouse pointer to over the newly opened Hovercard and then releases the mouse button.
3. Since the mouse cursor is still over the popup, as a user I expect the popup not to disappear. The reasoning is that, on the web when you click and drag away from the link without releasing the mouse button, your click isn't considered complete, thus you won't navigate away from the page.

I think this is an edge case and it's safe to close the hovercard. I can only see it mattering if user clicks the link before the hovercard loads, but even in that case, they can just hover again

My reading of this is that the behaviour is not important so I won't focus too much on it. I'll have a look at the other issue @bmansurov (avoiding sending dismissed events) flagged on my patch and fix that up.

The patches to review are:

• https://gerrit.wikimedia.org/r/#/c/311596
• https://gerrit.wikimedia.org/r/#/c/311753
• https://gerrit.wikimedia.org/r/#/c/311595

I'm currently idling so any help there would be great.

I acknowledge that I have created lots of patches for a 1 point task, but I think it's important to take every opportunity possible to reduce tech debt as this helps improve our efficiency on the long term. Having not been in the Hovercards extension for a period of 3 weeks I was lost and these kind of exercises help everyone.

I've written several hygiene patches that make this code more readable and easier to maintain. This refactoring exercise highlighted to me how events and rendering are tied together. The render method takes a jQuery.Event as a parameter and even aborts existing API requests. I've raised T146430 rather than continue working on refactoring (as refactoring is never done :-))

Patches that need review to complete this task are in this order:

• https://gerrit.wikimedia.org/r/312425
• https://gerrit.wikimedia.org/r/312426
• https://gerrit.wikimedia.org/r/312427
• https://gerrit.wikimedia.org/r/311753
• https://gerrit.wikimedia.org/r/311595

All changes but rEPOP9f12ab439766: Hygiene: Add set and get methods for active link have been +2'd by @bmansurov.

I've amended https://gerrit.wikimedia.org/r/#/c/312426/2 since it was the only bottle neck. I hope this is now good to go.

Change 311596 merged by jenkins-bot:
Clicking a Hovercards legible link should close popup

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

Could this be moved to Needs QA?

@ovasileva: You've just said that you're looking for tasks to add test plans to!

@phuedx - criteria added, but we still have to wait until this is deployed, so keeping it in ready for signoff

@ovasileva which browsers should this be tested on? All of https://www.mediawiki.org/wiki/Reading/Web/QA_device_and_browsers_list, just safari where the problem happened? safari + other normal browser?

From my testing this works on iOS 9 Safari and Android 4.x Web Browser. The Android 4.x and 6.x Chrome app I haven't been able to confirm step 5 because I don't see a swipe or back button to go back pages.

@Nicholas.tsg thank you. This only applies to the website. Sorry for making that unclear. Thank you for testing.

Wait. I thought we were aware of this behaviour? Nevertheless, I believe this'll be fixed by rEPOP4c18e17ee5fd: Hide Page Preview after opening link in different tab.

This seems strange unuseful behaviour to me and it does take some time to disappear on a slow connection even when you move the mouse. Was there a technical reason we accepted this behaviour @phuedx - did we document this anywhere?