Diecast Autoplays

By Shamus Posted Tuesday Mar 15, 2016

Filed under: Notices 35 comments

Dear valued Firefox reader: Yes, I know the Diecast is autoplaying when you visit the site. I’m just putting up this post as a catch-all so people don’t feel obliged to comment / email / tweet about it to me.

Sadly, it’s a bug in Firefox. Specifically, Firefox is incorrectly ignoring the autoplay=”false” directive. A few people have worked out the conditions required for the problem to manifest, which you can read about here.

Supposedly I could fix this by dumping the legacy <embed> tags and use only HTML5. That would (possibly) fix things for Firefox users, at the expense of people using old browsers or… pfft. I dunno. I don’t know how important the embed tag is, to be honest.

After some deliberation, I figured it’s a bad idea to punish non-Firefox people for the bugs in FF, so I’m keeping the embed for now. (Although I’d welcome some speculation / information on who uses it and how important it is.) As a temporary fix, I’ve moved the audio player off the front page for now. Hopefully the FF team gets this hammered out quickly.

 


From The Archives:
 

35 thoughts on “Diecast Autoplays

  1. hemebond says:

    Embed was not a part of HTML4. Surely most people are using a browser made in the last few years.

    1. Ardis Meade says:

      Your optimism is beautiful.

  2. This may or may not help you make a decision on the embed tag.

    caniuse.com info on the support of the audio tag. Is it really any point to support IE8 (and older) any longer?

    Wikipedia IE8 article:

    Internet Explorer 8 is the last version of Internet Explorer to run on Windows Server 2003 and Windows XP; the following version, Internet Explorer 9, works only on Windows Vista and later. Effective January 12, 2016, Internet Explorer 8 is no longer supported on any version of Windows

    I also suspect that anyone using Windows XP still are using Chrome or Firefox instead.

    Do you have any browser stats for the site? If so maybe you’ll be able to see if anyone are using browsers so old that they can’t handle HTML audio tags.

    BTW! You might want to remove the autoplay=”false” and autostart=”false”
    I suspect that with embed it’s possible these are treated as bolean so by actually specifying them you are setting them to true. autoplay=”false” might just evaluate to the same as autoplay=”true”
    In other words you either use autoplay=”true” to enable and to disable you leave it out fully (and the browser should default to not autoplay).

    You might also look at using object instead of embed.
    And you may also need to add type=”audio/mpeg” to the embed part as one version of chrome reportedly ignore setting autostart false unless that was specified.

    PS! Leaving out the autostart and autoplay attributes on all of the tags might be the better choice, the browser defaults to not playing and you save a few bytes.

    1. Dr_Fred says:

      The bit about “false” not being actually false reads kind of true (heh).

      Here is a recap table for equality testing in JS and it appears that neither “true” nor “false” are equal to true — or false. I don’t know if Javascript is actually involved in the problem (or why anyone would want to use the JS ‘==’ operator along with its insane semantics), but it could be an explanation.

      Or it could be, well, not that. But it would make sense. So to speak.

      1. It’s not related to javascipt actually. It’s that these attributes are possibly “pseudo-boolean”, there are a few of those in HTML

        Weird stuff like the input field attribute required=”required” which is the same as just using required with no value and it’s considered a boolean true. But using required=”” would count as it not being set and being a boolean false.
        HTML (aka HTML5) is pretty well defined now. This means that one must read up on the documented behavior of stuff. Mozillas MDN is probably the best reference for stuff like this.

        But back to your mention of javascript. Yep true and false is kinda weird at times. And then you got the use of === and !== which behaves slightly differently from that.
        In PHP (and to some extent Javascript) you sometimes must check using === rather than == or stuff will test differently than expected (and your code will break).

        1. Retsam says:

          With JS, the standard is to always use === and just pretend == doesn’t exist. === behaves pretty much like the equality operators in any other language, without doing any of the type conversion that == does. (The only unexpected behavior I can think of with === is that NaN is never considered equal to anything, including NaN)

          I always set up my static analysis tool to mark any usages of == as errors, so it’s never an issue.

          It’s unfortunate that the more obvious operator isn’t the one that you want to use, but I think people make a bigger deal of it than it needs be.

    2. Humanoid says:

      Some testing:

      Embed tag within Audio tag:
      Firefox: Shows widget, autoplays independently of widget.
      Opera: Shows widget, no autoplay.
      Edge: Shows widget, no autoplay.

      Embed tag within Audio tag, removed autoplay and autostart attributes from embed:
      All browsers: No change to the above.

      Embed tag standalone, autoplay/autostart attributes (false) present:
      Firefox: Widget shows, autoplays but uses widget, hitting stop stops the audio.
      Opera: Same as Firefox.
      Edge: No widget, no playback, no anything except a blank white screen.

      Embed tag standalone, removed autoplay/autostart attributes:
      All browsers: No change to the above.

      ________________

      From this I would say the following are true:

      a) The autoplay and autostart attributes do not, and likely have not ever done anything, they are simply not supported by the embed tag. The documentation for it, along with Opera blindly autoplaying it, seems to support this.

      b) This documentation for the audio tag suggests that plain text within the tag will be displayed instead of the audio widget for browsers that don’t support HTML5. (I know it’s not the “official” documentation, but the W3C site doesn’t even mention fallbacks and therefore is decidedly Not Useful)

      c) Opera treats the embed tag within the audio tag as “plain text” and therefore only uses it in the fallback case. Firefox processes it regardless.

      d) Edge has dropped support of the embed tag altogether.

      One final test has me enter in some actual plain text within the audio tag. None of the three browsers display it, which is correct behaviour. Therefore I would conclude that the the issue here is that Firefox is seemingly intentionally treating tags within the audio tags as fair game, whereas Opera (and presumably Chrome which I think shares the same rendering engine these days) treats it like it would ordinary text and reserve it for fallback purposes only. The whole autoplay/autostart thing is a likely red herring.

      1. Shamus says:

        So from this we can conclude that:

        1) Removing the embed tag wouldn’t really hurt anything, but…
        2) It also wouldn’t help fix Firefox, which is just determined to autoplay in all cases.

        1. Humanoid says:

          No no, Firefox won’t autoplay the audio tag, so it would be a solution. Firefox is simply treating an embed tag within an audio tag the same as it would treat an embed tag anywhere else, whereas other Opera(/Chrome) treat it as if it weren’t there. Embeds outside of audio tags would autoplay on any browser that supports the embed tag.

          Actually that brings up an interesting point: since embeds always autoplay, anyone visiting the site with a non-HTML5 compliant browser would get the embed, and it would presumably autoplay for them. Assuming there are any such people, of course.

          _________

          I can’t even begin to explain why having the VLC player plugin prevents the nested embed tag from autoplaying though, especially as it’s not even being used by the page – it’s incomprehensible.

          1. krellen says:

            Possible answer: it could be that VLC’s plugin does honour autoplay=false tags, overriding what Firefox wants to do with it.

          2. xKiv says:

            This would explain why hitting “play” on the (visible) widget ends up playing *twice* (at different offsets, obviously).

            Unsatisfying workaround: click the speaker-icon-thingy in the tab’s … tab, then firefox will mute all sound from the tab (but it’s still playing, so if you want to hear it from the start, you have to reload page or open just the diecast post).

  3. I run Firefox Nightly (currently at 48.x) and it didn't autoplay Diecast #145 when I loaded up the page. So, looks like a fix will be forthcoming.

  4. The Stranger says:

    I use Firefox (44.0.2) and I’ve never had Diecast autoplay. I can’t explain this, just wanted to confuse the issue a bit more.

    1. Ysen says:

      I also use Firefox and have never had the Diecast autoplay.

      1. Humanoid says:

        This has only been happening as of Firefox 45.0 which was released this past week.

        1. Muspel says:

          I’m using Firefox 45, and it doesn’t autoplay for me.

          1. Trix2000 says:

            Same for me, though as I mentioned before on forums I’m really confused on why I don’t have the issue given the circumstances…

    2. Scampi82 says:

      As I’m big in the business of confusing people, I agree. I also use Firefox and the Diecast doesn’t autoplay. It appears it’s just now attempting to update itself, so I’ll see if there will be a difference once it’s applied.

      1. Scampi says:

        So…update’s complete, I’m up to 45. now and still Diecast doesn’t autoplay. There must be something in the depth of my system that prevents it from doing so.

        1. krellen says:

          Check your audio-plugin settings. If you’ve installed VLC (and thus VLC is set as your browser’s audio plugin), that somehow fixes the bug. (If you change your audio plugin to use Windows Media Player, it’s likely you will replicate the bug.)

          1. Hitch says:

            I’m in the same situation as Scampi. I use Firefox (currently on 45) and have never had a problem with the Diecast autoplaying. As per Krellen’s comment I have VLC installed. So it sounds to me like (if I wanted to take sides in a pointless software war) Firefox is being unfairly blamed for a misbehaving Microsoft plugin (Windows Media Player).

            1. Humanoid says:

              Nah, it behaves like that with no plugin enabled. HTML5 players are implemented natively by the browser, and doesn’t require any third-party plugins.

              Besides, the bug appearing can be directly attributed to a Firefox version update, whereas the plugin likely has not updated anytime lately.

          2. LCF says:

            I’m using Firefox too, current version, with WMP as default for sound files, VLC installed and no VLC plug-in.
            Can’t remember having an autoplay on this here website.

            1. krellen says:

              You have to be using Firefox version 45 (the latest), as the bug was newly introduced. Anything older (and possibly also other betas) don’t have the problem.

  5. Disc says:

    Diecast #144 still shows up at the bottom of the frontpage and keeps autoplaying.

    I don’t know if it was obvious already, but I can actually get two broadcoasts coming at the same time if I also hit play on the widget.

  6. Neko says:

    The assortment of script-blocking addons I have is preventing autoplay for me, I guess. In any case, I don’t listen to it on the site, I wget it to my phone and go for a walk =)

  7. Matt K says:

    When I updated to the latest firefox I ran into this issue. The solution for me was to go into about:config and disabling media autoplay (http://www.ghacks.net/2015/06/07/how-to-disable-auto-playing-flash-and-html5-videos/) which fixed the issue.

    1. Humanoid says:

      Unfortunately it causes other media things like YouTube to behave quite oddly, as I described in the linked thread.

  8. ooli says:

    FF user, you might consider using Pale Moon.
    It’s a FF based browser, with all the good stuff without the recent shenanigan of FF (since v20).
    More importantly Shamus Website work perfectly with it.

  9. Sashas says:

    As one of the people who was experiencing the autoplay, have a fervent “thank you!” from me, Shamus.

  10. Kelhim says:

    Thank you, bucaneer, for your post in the forums:

    So another workaround […] would be to disable the stand-alone player by setting “media.play-stand-alone” to false.

    This did the trick for me! :)

  11. Steve C says:

    Have you tried clearing your trouser history? As shown here.

  12. General Karthos says:

    Behold what your open source has wrought! Gaze upon thy works and weep, as the taste of freedom turns to ash in thy mouths! Doom has come upon you, and he finds you lacking. Only the sweet oblivion of death can save you now.

    Seriously though… sucks. I moved from Safari to Firefox, and then from Firefox to Chrome. I can’t stomach Safari anymore. (Or “apps’r’us” apparently, now. I have to use them to edit http://swsheets.com, or I wouldn’t touch them with a ten-foot polearm) But I still like Firefox, even though Chrome is more convenient for a google (borg) drone such as myself. I hope whoever works on Firefox fixes it soon.

    And if they don’t, y’all can move to Chrome.

  13. Destrustor says:

    Wow, that’s weird.
    When this notice first appeared, it wasn’t a problem for me, and when I checked the site this morning, now it suddenly autoplays for some reason.
    And strangely enough, none of the diecasts currently visible on the front page seemed to be the culprit (unless the time bar fails to progress when this autoplay issue happens).

    1. Kelhim says:

      Have you updated your Firefox to 45.0? It’s a bug whith this version (and maybe following releases).

      You can set the option “media.play-stand-alone” to false (in about:config) as bucaneer suggested in the forums, which should fix the problem. I haven’t encountered any negative impacts, only the integrated media player doesn’t show up when you open a media file such as .ogg in the browser ““ instead, the download dialog appears. But I don’t find this particularly annoying.

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun. Your email address will not be published. Required fields are marked*

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="http://en.wikipedia.org/wiki/Darth_Vader">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>

Leave a Reply to Muspel Cancel reply

Your email address will not be published.