5 ms·

Firefox's default "allow autoplay after interaction" policy doesn't help much in the case of SPAs. Go to a site like ESPN and autoplay will be blocked on the fi

Firefox's default "allow autoplay after interaction" policy doesn't help much in the case of SPAs. Go to a site like ESPN and autoplay will be blocked on the first "page" you visit, but navigating to any subsequent "pages" ends up enabling autoplay since link clicks are intercepted and Javascripted away. What I really want browsers to adopt is an SPA breaking policy, where click handlers for <a> elements are ignored for non-whitelisted sites.

pier25 3y ago
Why would you want to break SPAs?
- caditinpiscinam 3y ago
  Because most SPAs that I interact with (like ESPN) have no business being SPAs (in the sense of hijacking navigation). The main motivation behind constructing them that way seems to be to circumvent UX safeguards.
  - pier25 3y ago
    Wouldn't it make more sense to just stop using apps like ESPN instead of breaking a major browser API and big chunk of the internet?
    - skydhash 3y ago
      Would you stop using GitHub as well. They recently move to a SPA models and I think search and readme links were broken for a few days because of history hijacking.
      - pier25 3y ago
        I wouldn't but my point is that a) no one is forcing anyone to use a website and b) it seems absurd to break a major browser API.
    - caditinpiscinam 3y ago
      The key to what I'm envisioning is that it wouldn't break a site like ESPN entirely -- it would just break the SPA behavior by making links behave like links. The end result is that the site would be more usable, not less. For sites where SPA behavior is necessary (like Spotify), opting in could be done with a one-time browser prompt, like how location access and DRM playback are handled. This seems like a more realistic solution than just avoiding these sites altogether, for the same reason that people use ad blockers instead of just shunning sites with ads.
      - pier25 3y ago
        > This seems like a more realistic solution It's completely unrealistic to break a major browser API.
        caditinpiscinam 3y ago
        How many web apps from 15 years ago still work? Flash, Java applets, browser specific hacks, fingerprinting, cross-origin shenanigans... all locked down or eliminated. The internet evolves by breaking APIs.
- zilti 3y ago
  Because they deserve to get broken.
Spivak 3y ago
So SPAs would stop using a elements, style buttons like links, and attach handlers to those. I don't think you'll be able to accomplish what you want.
- caditinpiscinam 3y ago
  They could get rid of links, but that would break search engine indexing. This wouldn't be an issue for legitimate SPAs like Gmail, but would be disastrous for content-based sites. More likely is that they'd keep <a> elements but hide them from the user. Either way, my proposal would make sites that eliminated or hid <a> elements stop working by default, which would disincentivize hostile UX practices.
PoignardAzur 3y ago
It helps if you're the kind of person who only ever opens links in new tabs. Firefox is way better for me than Chrome when I do that. Eg if I'm browsing Youtube's front page and I middle-click three videos in a row, I don't want all of them to start playing at the same time.
- pier25 3y ago
  Not sure if I enabled some Chrome setting or what but when I middle click on a Youtube thumbnail the video won't start playing until I focus on that tab.
akira2501 3y ago
> where click handlers for <a> elements None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root element, then let the individual clicks bubble up to there. We use data parameters on the individual elements, and if the click handler sees one of those, then it activates the history state/navigation. In terms of autoplay, a trick we have to play for iOS is, when you click on something we play a 0.25 second silent MP3 through the audio element. Once that's done, it's "active" and we can use it to play audio. It's a radio "boombox" type application, so this feature is expected by our users to keep audio playing when they navigate to different features within the player.
- caditinpiscinam 3y ago
  That makes sense for an audio-player application -- something like Spotify where the user expects playback to continue when navigating pages. Even so, I rely on the fact that Spotify links are actual links, so that I can open multiple tabs when I need to, for example when putting together a complicated playlist. Have you considered keeping <a> links as a fallback to support this sort of use-case?
- MrJohz 3y ago
  > None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root element, then let the individual clicks bubble up to there. We use data parameters on the individual elements, and if the click handler sees one of those, then it activates the history state/navigation. This breaks a lot of navigation features though, right? For example, middle click or control click to open in a new tab, hovering to see where the link will take you, right clicking to save, copy, or share a link, etc. Why not just have them be anchor elements with hrefs that refer to the URL that you'll be using the history state with? You can still listen to the click events and perform the required history updates and navigation when that occurs, but if the user interacts with that link outside of just clicking it, it'll behave as they expect. Depending on how your navigation works, this could well be less work overall - this has certainly been my experience with similar projects.

pier25 3y ago

Why would you want to break SPAs?

caditinpiscinam 3y ago
Because most SPAs that I interact with (like ESPN) have no business being SPAs (in the sense of hijacking navigation). The main motivation behind constructing them that way seems to be to circumvent UX safeguards.
- pier25 3y ago
  Wouldn't it make more sense to just stop using apps like ESPN instead of breaking a major browser API and big chunk of the internet?
  - skydhash 3y ago
    Would you stop using GitHub as well. They recently move to a SPA models and I think search and readme links were broken for a few days because of history hijacking.
    - pier25 3y ago
      I wouldn't but my point is that a) no one is forcing anyone to use a website and b) it seems absurd to break a major browser API.
  - caditinpiscinam 3y ago
    The key to what I'm envisioning is that it wouldn't break a site like ESPN entirely -- it would just break the SPA behavior by making links behave like links. The end result is that the site would be more usable, not less. For sites where SPA behavior is necessary (like Spotify), opting in could be done with a one-time browser prompt, like how location access and DRM playback are handled. This seems like a more realistic solution than just avoiding these sites altogether, for the same reason that people use ad blockers instead of just shunning sites with ads.
    - pier25 3y ago
      > This seems like a more realistic solution It's completely unrealistic to break a major browser API.
      - caditinpiscinam 3y ago
        How many web apps from 15 years ago still work? Flash, Java applets, browser specific hacks, fingerprinting, cross-origin shenanigans... all locked down or eliminated. The internet evolves by breaking APIs.
zilti 3y ago
Because they deserve to get broken.

Spivak 3y ago

So SPAs would stop using a elements, style buttons like links, and attach handlers to those. I don't think you'll be able to accomplish what you want.

caditinpiscinam 3y ago
They could get rid of links, but that would break search engine indexing. This wouldn't be an issue for legitimate SPAs like Gmail, but would be disastrous for content-based sites. More likely is that they'd keep <a> elements but hide them from the user. Either way, my proposal would make sites that eliminated or hid <a> elements stop working by default, which would disincentivize hostile UX practices.

PoignardAzur 3y ago

It helps if you're the kind of person who only ever opens links in new tabs. Firefox is way better for me than Chrome when I do that. Eg if I'm browsing Youtube's front page and I middle-click three videos in a row, I don't want all of them to start playing at the same time.

pier25 3y ago
Not sure if I enabled some Chrome setting or what but when I middle click on a Youtube thumbnail the video won't start playing until I focus on that tab.

akira2501 3y ago

> where click handlers for <a> elements None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root element, then let the individual clicks bubble up to there. We use data parameters on the individual elements, and if the click handler sees one of those, then it activates the history state/navigation. In terms of autoplay, a trick we have to play for iOS is, when you click on something we play a 0.25 second silent MP3 through the audio element. Once that's done, it's "active" and we can use it to play audio. It's a radio "boombox" type application, so this feature is expected by our users to keep audio playing when they navigate to different features within the player.

caditinpiscinam 3y ago
That makes sense for an audio-player application -- something like Spotify where the user expects playback to continue when navigating pages. Even so, I rely on the fact that Spotify links are actual links, so that I can open multiple tabs when I need to, for example when putting together a complicated playlist. Have you considered keeping <a> links as a fallback to support this sort of use-case?
MrJohz 3y ago
> None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root element, then let the individual clicks bubble up to there. We use data parameters on the individual elements, and if the click handler sees one of those, then it activates the history state/navigation. This breaks a lot of navigation features though, right? For example, middle click or control click to open in a new tab, hovering to see where the link will take you, right clicking to save, copy, or share a link, etc. Why not just have them be anchor elements with hrefs that refer to the URL that you'll be using the history state with? You can still listen to the click events and perform the required history updates and navigation when that occurs, but if the user interacts with that link outside of just clicking it, it'll behave as they expect. Depending on how your navigation works, this could well be less work overall - this has certainly been my experience with similar projects.