[JW8-10549] Fix the controls not autohiding on mobile

[mamaddox]

This PR will...

• Fix the issue where controls were not automatically hiding when the user was inactive for 4 seconds on mobile.

Why is this Pull Request needed?

• Bug fix

Are there any points in the code the reviewer needs to double check?

Are there any Pull Requests open in other repos which need to be merged with this?

Addresses Issue(s):

JW8-10549

Checklist

• Jenkins builds and unit tests are passing
• I have reviewed the automated results

[jnatalzia]

@mamaddox the changes here make sense but could i get a quick explainer of the issue underlying it? was the initial mouse handler causing some unintentional state with regards to the controls hiding?

[jwplayer-robot]

⚠️ MULTI Build for commit 5c6baa3 is unstable (FAILURE).
🏗 jwplayer build SUCCESS
🏗 jwplayer unit tests SUCCESS
🏗 jwplayer-commercial build SUCCESS
🏗 jwplayer-commercial unit tests SUCCESS
🥒.js Allure Report FAILURE
🥒 Allure Report UNSTABLE
🍆 Manual Tests
📺 Views

[mamaddox]

As far as my understanding goes, this issue was occurring only if the user selected a control in the control bar after hitting play, but before the first userInactive event occurred.
When this happened, a mousemove event was triggered inside the controlbar that set the activeTimeout to zero and didn't invoke the userInactiveTimeout. However, when the user tapped the screen, the mouseevent listeners were removed so things went back to normal. It seemed like those event listeners were not needed since they always got removed whenever the screen was tapped.

But now that I'm thinking about it, is there a case where mobile needs both mouse and tap events?

[jnatalzia]

But now that I'm thinking about it, is there a case where mobile needs both mouse and tap events?

I can't think of one, especially if we were immediately removing those listeners on tap anyway.

[jnatalzia]

Hmm thinking about it, there's the possibility that older devices don't support the touch events and therefore would never hit the execution path where they are removed.

Support looks really good across mobile browsers though so I don't think this concern is justified
https://developer.mozilla.org/en-US/docs/Web/API/Touch_events