Page MenuHomePhabricator

Don't show hovercard after clicking a link
Closed, InvalidPublic1 Story Points

Description

When clicking a hovercard in safari and going back the hovercard will still be open

Ac

  • When clicking a link/hovercard the hovercard disappears or doesn't show up clicked before appearing.
  • Event logging behavior is unchanged (clicking a link only sends the 'opened in ...' event, no 'dismissed' or 'dwellbutabandoned')

Original report

Hovercards remain visible when using back button in Safari

Safari handles the back button a little differently than other browsers. When navigating back it retrieves the page from a cache including the last state of DOM objects. This causes Hovercards to remain open when navigating back (after clicking a hovercard-ed link).

First mentioned here: https://www.mediawiki.org/wiki/Topic:T99cxk1ojrf4y5tn

The suggestion is to figure out a way to dismiss these hovercards when navigating back - which at fist blush appears to involve invalidating Safari's (and Firefox?) cache.

See also:
https://madhatted.com/2013/6/16/you-do-not-understand-browser-history
http://stackoverflow.com/questions/8788802/prevent-safari-loading-from-cache-when-back-button-is-clicked

Testing criteria

  1. Log in
  2. Enable hovercards as beta feature
  3. Hover over a link and click the link to proceed to next page
  4. Hovercard should close
  5. If back button is pressed, no hovercards should appear

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 15 2016, 9:32 PM
Jdlrobson triaged this task as Normal priority.Aug 16 2016, 5:16 PM
Jdlrobson added a project: Readers-Web-Backlog.
Jdlrobson added a subscriber: Jdlrobson.

This sounds like a potentially good feature if it worked on all browsers.

Jhernandez renamed this task from Hovercards remain visible when using back button in Safari to Don't show hovercards when clicking a link.Sep 7 2016, 3:54 PM
Jhernandez updated the task description. (Show Details)
Jhernandez renamed this task from Don't show hovercards when clicking a link to Don't show hovercard after clicking a link.
Jhernandez updated the task description. (Show Details)
Jhernandez updated the task description. (Show Details)Sep 7 2016, 3:56 PM
ovasileva raised the priority of this task from Normal to High.Sep 7 2016, 3:56 PM
ovasileva updated the task description. (Show Details)
Jhernandez updated the task description. (Show Details)Sep 7 2016, 3:58 PM
Jdlrobson set the point value for this task to 1.Sep 8 2016, 6:31 PM

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.

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.

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:

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 reassigned this task from Jdlrobson to ovasileva.Sep 27 2016, 5:06 PM
ovasileva updated the task description. (Show Details)Sep 28 2016, 12:34 PM

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

ovasileva closed this task as Resolved.Oct 6 2016, 1:07 PM

also tested, works fine

Jdlrobson reopened this task as Open.Mar 9 2017, 10:37 PM
Jdlrobson removed a project: Patch-For-Review.

This bug seems to have returned.

Jdlrobson removed ovasileva as the assignee of this task.Mar 10 2017, 6:00 PM
Jdlrobson moved this task from 2016-17 Q2 to Triaged but Future on the Readers-Web-Backlog board.

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.

ovasileva closed this task as Invalid.Mar 14 2017, 4:58 PM

@Jdlrobson, @phuedx - yes, the behavior is acceptable so long as users can move the cursor and the card will disappear (not acceptable if the user has to click to make the preview disappear. Closing for now.

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?