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

mobileAutoEnable totally breaks Chrome's touch events #1003

Closed
kamkha opened this issue Jul 20, 2018 · 3 comments
Closed

mobileAutoEnable totally breaks Chrome's touch events #1003

kamkha opened this issue Jul 20, 2018 · 3 comments
Labels

Comments

@kamkha
Copy link

kamkha commented Jul 20, 2018

Now that Howler is running its event-based auto-enable on Chrome, all touch events are broken due to Chrome forcing document-level touch handlers to be passive.

image
(Clickable link from the image: https://www.chromestatus.com/features/5093566007214080)

To reproduce:

  1. Load any page that includes howler.js 2.0.14 and initializes a Howl object in Chrome, like any of the demos on https://howlerjs.com/.
  2. If on desktop, enter mobile-emulation mode: open the DevTools (⌘ ⌥ i on Mac) and then the device toolbar (⌘ ⇧ m), and ensure "Mobile" is selected as the "Device type" (so that the typical mouse events are instead emulated touch events).
  3. Try to interact with the document by clicking on any element, scrolling with the cursor, etc. — nothing will happen.

Howler's document-level touchstart event handler calls preventDefault on the event, but recent versions of Chrome force touchstart event handlers — and other potentially scroll-blocking handlers — to be passive (see the relevant item in the Chrome platform changelog). Passive events can't have their default actions prevented, so Howler's unlock handler throws an error which breaks that touch event and prevents interaction with the document.

This is affecting Chrome desktop and Chrome for Android version 56 and above, including web views on Android.

A quick fix would involve checking that unlock handler to make sure it isn't passive before preventing its default handler. However, it's unclear to me why the default handler should be prevented at all, as that unlock method seems like it should always be passive — perhaps that line can be removed altogether?

@goldfire goldfire added the bug label Jul 20, 2018
@benwick
Copy link

benwick commented Aug 2, 2018

If the line serves no purpose, we should remove it. Because it breaks the opening of links in chrome... #1011

The preventDefault call was added with the last release. For what reason?

@FiveHundredMiles
Copy link

I encountered this error in my app after I updated the library to v2.0.14 yesterday.
But, except for the error message, it looks like everything is still functioning on my app (the audio part).

Will anyone be kind enough to share the code on how can I implement a quick fix to get rid of the error message? Something we can just cut and paste the code - because some of us like me don't really understand how the audio part works. :-) Thank you so much in advance.

@goldfire
Copy link
Owner

Thanks, this has now been fixed and I'll get a v2.0.15 out soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants