4

I've added a video to my site using the default HTML5 video player. The code is like this:

<video width="100%" height="100%" controls>
  <source src="http://media.sublimevideo.net/v/midnight-sun-short-edit-360p.mp4" type="video/mp4">
</video>

I wanted to make it so a click on the video stops or starts the video. So I added this:

onclick="this.paused?this.play():this.pause();"

And all good. Until Firefox 35 adds this very function to the player. So now you can only play the video by right clicking and selecting play - an ordinary click would first make the video play via the native behaviour, and then immediately pause it via my click handler. Terrible. So I thought up a JavaScript function something like this:

function startstop() {
  if ( FirefoxVersionNumber > 34 ) {
    // do nothing
  } else {
    // start or stop video
  }
}

The bit I'm stuck on is how to check the browser version? All the ones I tried returned that Firefox version number was 5... which I think comes from the Netscape part.

Mark Amery
  • 143,130
  • 81
  • 406
  • 459
user111223
  • 41
  • 3
  • 2
    Detecting the browser version is typically considered to be the poorest possible way to implement differing behavior to accommodate browser features - the preferred way to handle it would be through a concept called "feature detection", where instead of coding for one specific browser, you'd want to just try to detect whether or not that functionality is already present and then only add it if necessary. Not sure what that would look like in this case but it's something to think about. – Sam Hanley Feb 05 '15 at 20:26
  • Yes I had thought this, but as the video player has only been upgraded - the feature detection would detect if the html5 video tag is supported (i imagine?) – user111223 Feb 05 '15 at 20:29
  • Yeah, I don't know how you would detect that specific feature of the video player. But you may want to spend some time investigating if there would be any way to do so, because browser sniffing should generally speaking be considered last resort. – Sam Hanley Feb 05 '15 at 20:30
  • Interestingly, the developer release notes for Firefox 35 (https://developer.mozilla.org/en-US/Firefox/Releases/35#Audio.2FVideo) says there's no changes related to audio or video. Are you sure that Firefox 35 is specifically at fault? – Sam Hanley Feb 05 '15 at 20:32
  • http://stackoverflow.com/questions/5278262/click-the-poster-image-the-html5-video-plays - look at the comment on the answer - and i can verify it on windows too – user111223 Feb 05 '15 at 20:34
  • 1
    It's *not* Firefox 35 that adds click-to-play/pause functionality. I have it in Firefox 34 (a fresh install thereof with no plugins - I use Chrome normally) on the machine I'm commenting from right now - I can go to http://jsfiddle.net/3oeue4ot/ and click anywhere on the video to make it play. – Mark Amery Feb 05 '15 at 21:39

2 Answers2

4

You need to prevent the default behaviour of the click event, in much the same way that you would prevent the default behaviour of a form submit if you were handling it yourself with JavaScript.

Event.preventDefault is the tool for the job.

Just do

video.addEventListener('click', function (event) {
    event.preventDefault(); // Prevent the default behaviour in Firefox

    // Then toggle the video ourselves
    if (this.paused) {
        this.play();
    }
    else {
        this.pause();
    }
});

Here's a Fiddle that works both in Chrome (which has no built-in click-to-toggle behaviour on videos) and in Firefox (which, at least in recent versions, does): http://jsfiddle.net/LjLgkk71/

As an aside, as a general rule you should forget browser sniffing until you've truly and utterly exhausted all other avenues (with the exception of using it to work around specific known quirks and bugs in old browsers, relating to behaviour that has since been fixed or standardised). The idea you expressed in the question, of simply not applying your click handler on certain browser versions, was misguided; you have no way of knowing (and nor do I) what other browsers share or will one day share Firefox's behaviour. If you'd taken your approach, it's almost inevitable that it would come back to bite you either when one of the major browsers followed Firefox's example or when one of your users tried to use your site on a Nintendo DS or something.

Mark Amery
  • 143,130
  • 81
  • 406
  • 459
0

There may very likely be better ways to handle this, but here's one that I've come up with: I looked through the release notes for Firefox 35, and it looks like one of the changes made in 35 was fixing a bug where a method called .hasAttributes() that, according to spec, is supposed to be located on Element was previously located on Node. So, although it looks odd, you could do something like:

if(typeof InstallTrigger !== 'undefined' && 
   typeof Element.prototype.hasAttributes !== 'undefined') {
    // is Firefox >= 35
} 

This is based on the fact that typeof InstallTrigger !== 'undefined' would identify Firefox as per this answer and we know .hasAttributes moved to Element beginning in version 35. This would be preferable to user agent parsing because unlike the User Agent string it is unlikely to be spoofed in any way.

It's been mentioned in the comments that it seems odd to do a form of browser detection by checking for the presence of an unrelated JavaScript object - but this is a practice that's established and has been used historically to detect versions of a specific browser greater than a certain version: Here's an article that describes commonly used variables that can be used to detect Internet Explorer versions >= a given number.

Community
  • 1
  • 1
Sam Hanley
  • 4,707
  • 7
  • 35
  • 63
  • This fails to check that you're actually in Firefox, though, which stops it from being useful. I'm intrigued, by the way, by the argument that it's better to do user agent sniffing indirectly via detection of some random feature unrelated to the one you're interested in, just to avoid the perils of actual user agent parsing. It feels like an incredibly *ugly* thing to do, but there is a certain logic to it. – Mark Amery Feb 05 '15 at 21:45
  • 1
    As you suspected, there is indeed [a better way](http://stackoverflow.com/a/28354941/1709587) to approach this, which I found after a lot of tinkering. – Mark Amery Feb 05 '15 at 22:17
  • 1
    It does check that you're in Firefox - the InstallTrigger object is nonstandard and only exists in Firefox, as explained in the cited answer. Glad you found a better solution though. And as a side note - there's a long history of using unrelated features to detect specific browser versions, I'll find related links later. – Sam Hanley Feb 06 '15 at 00:19
  • Oops, my apologies for that - it was explained right there in your answer, too, but I didn't read. Poor show on my part. – Mark Amery Feb 06 '15 at 00:21
  • No worries! It's admittedly a weird check, but one that I found through a link within the link the OP posted in the contents. – Sam Hanley Feb 06 '15 at 00:23
  • @MarkAmery, if you're interested in the argument re: detection of random feature rather than user agent parsing, see the link I added to the answer on historically using this practice to distinguish IE versions. – Sam Hanley Feb 06 '15 at 15:24