Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

T256213: Add a small delay to onMouseLeave #20

Merged
merged 6 commits into from
Jul 27, 2020

Conversation

medied
Copy link
Contributor

@medied medied commented Jul 9, 2020

Phab ticket: https://phabricator.wikimedia.org/T256213

What's needed:

add a small delay to the closing of the popup when the mouse leaves the word

We tested a few delays with this demo branch and we're setting delay to 300ms based on that.

Copy link
Collaborator

@stephanebisson stephanebisson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is to prevent a quick "exit and re-enter" from closing the popup. This code is subject to race conditions between the closing after the delay and reopening in new mouseenter events. Put console.log in the events and you'll see what's going on. Ideally, a new mouseenter event should clearTimeout instead of trying to trigger a new opening.

@medied
Copy link
Contributor Author

medied commented Jul 10, 2020

I had slightly misunderstood the ticket, you're right. How about 9c2f063? The more we test it, the better

src/event.js Outdated
@@ -5,7 +5,22 @@ export const customEvents = popup => {
const toElement = e.toElement || e.relatedTarget || e.target
if ( toElement !== popup.element.currentTargetElement &&
!popup.element.contains( toElement ) ) {
popup.hide()
let timeoutId
const previewElement = popup.element.currentTargetElement,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

popup.element.currentTargetElement used twice within the same scope, let's define previewElement in the top of the scope.

hueitan
hueitan previously approved these changes Jul 13, 2020
Copy link
Member

@hueitan hueitan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 It looks good to me, ready for test.

@jpita
Copy link
Contributor

jpita commented Jul 14, 2020

Tested on android, windows (IE, Chrome and FF) and mac.
Found this small issue when 2 words are together.
When I move from one word immediately to the other, the popup on the 2nd word closes even though the mouse is over the 2nd word.
It seems we are not detecting the 2nd mouse-enter and stopping the timer.
Jul-14-2020 15-41-43

@hueitan
Copy link
Member

hueitan commented Jul 14, 2020

Tested on android, windows (IE, Chrome and FF) and mac.
Found this small issue when 2 words are together.
When I move from one word immediately to the other, the popup on the 2nd word closes even though the mouse is over the 2nd word.
It seems we are not detecting the 2nd mouse-enter and stopping the timer.

🥇 for u @jpita!!!! I can confirm this behaviour and we need to fix it.

@hueitan hueitan dismissed their stale review July 14, 2020 09:19

review again after the fix

@hueitan
Copy link
Member

hueitan commented Jul 14, 2020

Following what Pita found, what if when user mouse leaves the popup/previewElement to another wikipedia hyperlinks, then mouse move back to the popup, ALL within 300ms, do we show the new popup or keep the current popup? I think the latter. If so our code need to do extra guard here.

EDIT : just check on PagePreviews on the Wikipedia website, it opens the new popup immediately when use mouse hover the new hyperlink.

src/index.js Show resolved Hide resolved
@hueitan
Copy link
Member

hueitan commented Jul 16, 2020

note : to review this beb4a3a

@hueitan hueitan mentioned this pull request Jul 17, 2020
@jpita
Copy link
Contributor

jpita commented Jul 19, 2020

this still has pending changes, right?

@stephanebisson
Copy link
Collaborator

Works well as far as I can tell but we need unit tests to verify the different scenarios: exit, exit and re-enter the same link or popup, exit and re-enter a different link.

@medied
Copy link
Contributor Author

medied commented Jul 21, 2020

Yes as of e1e18a4 the expected behavior is overall working well but under the hood there are some event listeners we are still failing to remove. To address this, we are in the process of merging #23 into this PR.

Also, as noted in #23, when you are QAing this PR @jpita keep in mind that transitioning from a preview in one language to another one in a different language (all within 300ms) you will see a buggy behavior. We plan to address this in a new ticket

hueitan and others added 2 commits July 21, 2020 10:48
* POC - stack all event listener and timeout event

* remove unused comment line

* naming clearAllEventListener

* var -> let
@@ -16,7 +16,9 @@ function init( {
createPopup( popupContainer ),
events = customEvents( popup ),
showPopup = ( { target } ) => {
popup.hide()
if ( popup.element.style.visibility === 'visible' ) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hueitan just FYI: I realized tonight that always executing popup.hide() without a check was breaking the previews in mobile with the error below (it tries to remove a background screen that's not there), so I'm including this conditional

Uncaught TypeError: Node.removeChild: Argument 1 is not an object.
    removeBackgroundScreen webpack://wikipediaPreview/./src/touchPopup.js?:17
    hide webpack://wikipediaPreview/./src/touchPopup.js?:49
    showPopup webpack://wikipediaPreview/./src/index.js?:31

@medied
Copy link
Contributor Author

medied commented Jul 22, 2020

...but we need unit tests to verify the different scenarios

Huei and I suspected these tests would be somewhat tricky/particular, I gave it a first try today and indeed ran into issues on how to approach them and think about measuring timing. I'm looking to pick someone's brain to understand what makes most sense. For what it's worth, this sub-branch shows what I tried: T256213-hover-closing-delay-tests-exploration.

@stephanebisson would you say the tests here are a merge blocker?

Either way, @jpita I'd say you can now start QAing this ticket. Just don't merge to master until we settle on tests

@jpita
Copy link
Contributor

jpita commented Jul 22, 2020

Either way, @jpita I'd say you can now start QAing this ticket. Just don't merge to master until we settle on tests

will move the task to code review until the code is finished so it's not stuck in QA

@hueitan
Copy link
Member

hueitan commented Jul 22, 2020

Huei and I suspected these tests would be somewhat tricky/particular, I gave it a first try today and indeed ran into issues on how to approach them and think about measuring timing. I'm looking to pick someone's brain to understand what makes most sense. For what it's worth, this sub-branch shows what I tried: T256213-hover-closing-delay-tests-exploration.

@stephanebisson would you say the tests here are a merge blocker?

This is really tricky, this approach is going into an integration test which is not a unit test anymore.

I would suggest don't let this be the merge blocker, the unit test (only event.js) or e2e test (integration) should cover this scenario + this as well #23 (comment),

@jpita
Copy link
Contributor

jpita commented Jul 22, 2020

I can see what I can do with cypress
https://phabricator.wikimedia.org/T258574

@hueitan
Copy link
Member

hueitan commented Jul 23, 2020

We should move on, @jpita, currently there is 0% in the integration test, let's qa this then feel free to add them later.

@jpita
Copy link
Contributor

jpita commented Jul 24, 2020

ok, this is tested, feel free to merge when you think is ready

@stephanebisson stephanebisson merged commit 513b876 into master Jul 27, 2020
@stephanebisson stephanebisson deleted the T256213-hover-closing-delay branch July 27, 2020 10:49
@stephanebisson stephanebisson restored the T256213-hover-closing-delay branch May 13, 2021 17:27
@stephanebisson stephanebisson deleted the T256213-hover-closing-delay branch May 13, 2021 17:31
@stephanebisson stephanebisson restored the T256213-hover-closing-delay branch July 28, 2022 12:56
@stephanebisson stephanebisson deleted the T256213-hover-closing-delay branch July 28, 2022 13:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants