8tracks shows "Copy" button whenever play/next/pause is pressed

Investigating the issue, on the play screen, I’m seeing touchstart events, but no touchend events.

The mechanism that detects long presses uses a timeout of 800ms that’s fired on touchstart, and touchend interrupts it. If there are no touchend events, then every single touch is incorrectly detected as a long press.

Now I need to understand how 8tracks can possibly swallow the touchend events.

For the sake of completeness, the selection.js script should also listen for 'touchcancel' events and clear the timeout when they happen, so I’ll add this. However in this specific case we’re not even getting touchcancel events, so the problem lies elsewhere.

Using the monitorEvents function (https://developers.google.com/chrome-developer-tools/docs/console#monitoring_events) in the inspector, I can confirm that only the touchstart events are emitted, not the touchend ones.

It looks like 8tracks has some custom event handlers for touchstart, touchmove and touchend events, and some of them may call event.preventDefault() under certain circumstances, thus preventing the event from reaching the selection script. Meaning, there’s nothing we can do about it, except maybe for blacklisting the script for webapps known not to play well with it.

I’ve added a blacklist mechanism that will not install the selection event handlers for a list of domains known to interfere with touch events. This blacklist currently contains only one entry: "m.8tracks.com".

Hi guys, 8tracks lead web developer here. John Pugh was kind enough to alert us directly about this issue.

We bind to "touchend" events on mobile devices. We usually call "return false;" at the end of bound functions to prevent link touch events with valid href attributes from propagating and opening new tabs, etc. Perhaps it would be better to use "event.preventDefault()" instead? This is probably not necessary on the play/pause buttons in any case.

You can see how our events are bound in the uncompressed source JS below - look for the "pressEvent" variable which appears throughout to distinguish between touch-capable and mouse-capable browsers.
http://8tracks.com/m/js/E8tracksMobileUI.js

Let me know if you have any suggestions as to how this issue might be more easily resolved from our end.

Thanks,
Matthew

Thanks Matthew for getting in touch and for the pointer to the code.

So it looks to me like you would get the expected result (preventing touch events on links from propagating and opening new tabs) by just calling preventDefault() as you suggest, instead of returning false (which according to jQuery’s documentation is equivalent to calling both .preventDefault() and .stopPropagation() on the event object).

And that should ensure that the touchend event gets propagated to our userscript that detects long presses.

If that’s something you’re willing to consider changing on 8tracks, please let me know through this bug report, and I’ll remove the entry from the blacklist as soon as it’s in place. Thanks again!

This bug was fixed in the package webbrowser-app - 0.23+14.04.20140219-0ubuntu1

---------------
webbrowser-app (0.23+14.04.20140219-0ubuntu1) trusty; urgency=low

  [ Olivier Tilloy ]
  * Do not install the selection event handlers on certain domains known
    to interfere with touch events. (LP: #1279903)
 -- Ubuntu daily release <email address hidden> Wed, 19 Feb 2014 18:36:27 +0000

This is happening on twitter too - filed bug 1287749

For the record, this bug happens because:
 - webbrowser-app’s long-tap detection is implemented in JS as a userscript, using a combination of event handlers for touchstart and touchend events and a timer
 - 8tracks (and apparently other webapps, see bug #1287749) swallow the touchend event

Note that when we switch to oxide, we can use the 'contextmenu' event (which on touch is triggered on long tap) instead of implementing a custom long-tap detection mechanism. This means we will not be affected by webapps swallowing the touchend event any longer, i.e. this bug will automagically be fixed.

The switch to oxide is now complete, and with it this bug became invalid.