Posts Tagged ‘firefox’

Webkit vs. Firefox on H264

March 19th, 2010

I posted this as a comment on another thread; but I thought it warranted its own post.

Webkit is an open source project.
Webkit development is sponsored by corporations (Apple and Google primarily).
Webkit includes support for h264 video.

Firefox is an open source project.
Firefox development is sponsored by corporations (Mozilla Corporation primarily).
Firefox does not include support for h264 video.

...and yes, the webkit you can download from webkit.org includes h264 support. If Mozilla "can't" include H264 in Firefox which has been one of the primary arguments by commenters; I'm failing to see a reason.

  

Mozilla’s Not Non-profit (And Other Thoughts)

March 18th, 2010

Wow, I wrote my "Dear Mozilla..." post last night around 10:30 pm and in less than 12 hours it has generated more traffic than my Blog has generated in any single month since I launched it. As I expected, the open source pundits are out in force (and it's a good thing, they are certainly some valid points in their arguments). As always, there are a few bad apples in the mix who want to make this a personal argument and want to insult me for expressing my opinion. I'll ignore them for now because I don't want to get roped into that.

That said, some of the content of the comments has struck a chord with me so I want to add some additional thoughts. I encourage open and good natured discussion and I'll take the opportunity to remind everyone that one of the great pleasures of life is that we're allowed to disagree.  There are a lot of supporters on both sides of this argument that bring very valid concerns to the table.

First, I never said that Mozilla shouldn't support Theora (or that any browser shouldn't). My letter was about supporting H264; not dropping support for Theora.

I completely agree with the assertion by many that Microsoft's reason for supporting H.264 is to basically "throw egg" on Mozilla's face. Simply put: good strategy; my post is certainly not the only one out there talking about how Mozilla needs to add H.264 support now.

I'm going to say it: I don't care about Opera despite its users being quite possibly the loudest out there. They have abysmally small market share and,  I'm surprised it's closed source nature doesn't horrify those of you who are so concerned about "free as in speech" software. I have to say; it's a bit contradictory.

Mozilla's Not a Non-Profit

The most common argument has been that "Mozilla's just an open source project, they can't afford a license." I'm calling a great-big, giant bullshit on this one and I congratulate the Mozilla Corporation for so successfully pulling the wool over the eyes of so many people (even their linked in page for the Mozilla Corporation describes Mozilla as a non-profit; choosing to describe only the Mozilla Foundation and not the Mozilla Corporation itself). The Mozilla Corporation (which owns the rights and trademarks around Firefox - Colby Russel correctly points out in the comments that the Mozilla Foundation does actually own the rights to Firefox and its trademarks) is an extremely profitable company.  The browser is Free Software, but Mozilla's not this small project with no finances. They are very well funded and completely profitable.

Whether they should pay for a license is up for debate and we can have some really constructive discussion around that topic; but make no mistake, the Mozilla Corporation is not non-profit. Driving your profit back into your business does not make you non-profit; it means you're reinvesting your profit rather than paying shareholders.

I Really LIKE Firefox

But I'm sorry to say that pragmatism wins out over idealism every time; and I fear that if Mozilla chooses to continue on this path, Firefox will see its market share dwindle as it becomes about as popular as desktop linux (used by open source purists, but that's really about it). Personally, I don't want to see that happen. But the truth of Firefox's rise is that it was just a categorically better product than the competition. By not supporting the video format that is clearly emerging as dominant on the Web, that will no longer be the case.

  

Dear Mozilla, Please Don’t Kill HTML5 Video!

March 17th, 2010

Mozilla and I have a long and not-so-storied history together. I first began running what was at the time called the Mozilla App Suite with the "Milestone 10" release in October 1999. I was (I believe) one of the first people outside of the core team to build (as in compile) the browser that would come to be known as Firefox. It was called Phoenix at the time and the team hadn't released any binaries. I remember talking to the core team  on IRC getting instructions as to what build flags to add to build Phoenix rather than the app suite. For a time, I released unofficial nightly versions of Phoenix (then Firebird) compiled with Xft support for anti-aliasing on Linux that were distributed through MozillaZine. Long story short: I've contributed only slightly to the project; but I've supported it as long as anyone and generally my ideals match up nicely with the Mozilla team.

Until now.

I'm a huge supporter of open formats; I always have been. One of the main reasons Microsoft was able to rise to its Monopoly-level dominance was the proliferation of the proprietary MS Office file formats. However, I have reason to believe that Mozilla's decision not to support H.264 encoded video via the HTML5 video tag due to the "patent encumbrance" of the codec, is a wrong decision and one that, unless they change their mind, will kill any hope of ushering a new era of online video distribution that exists without plugins. Mozilla has always been an organization willing to take a stand for what they believe in; and they believe in the open web.

Three of Four

With Microsoft announcing support for H.264 video in IE9, three of the four "big name" browsers will be supporting H.264 video. Truthfully, this move surprised me when it was first announced; I had assumed, like others, that Microsoft would choose only to support their own proprietary format. The success of Office taught the team in Redmond that simply using proprietary formats isn't good enough; you have to completely own the format. However, without support from Mozilla, H.264 can never be the "encode once, deploy anywhere" format that people and businesses need it to be.

Encoding is slow and expensive

Video encoding is a very processor-intensive process; it's time consuming, expensive, and the resulting files are large which lead to bandwidth and storage costs. The current Flash implementations on the web are already H.264 capable, and much of the video content for the web is already encoded in H.264. It's nothing but an expense to create and maintain additional encodings. And even if we as web developers can create a robust fallback system that prevents the user-experience of online video from regressing to the days of "choose your format," the added costs are something most companies simply cannot ignore.

Theora Sucks

I say that harboring no ill-will towards the very talented engineers who have sunk countless hours of their time into Theora. But as numerous comparisons have shown, it simply can't keep up with H.264 in terms of quality; especially at low bitrates. MPEG2 was once considered great; but in the face of the current top-dog codec, it (like Theora) sucks. People and businesses are willing to embrace free software when it provides an equal or better product than the proprietary alternatives (see the success of Linux on the server). However, when free software doesn't keep up with the best non-free products, people stay away (see the lack of success of Linux on the desktop). Simply put, there just aren't that many people who share the same moral imperative as the Free Software Foundation; most of just want it to work.

There's a Precedent Too

Mozilla has a track record of not sharing the stance of "nothing proprietary," which implies that as an organization, Mozilla is willing to pick it's battles. If it wasn't, it wouldn't allow proprietary plugins like Flash. Imagine also if Mozilla had taken the same stance against GIF images in the early 2000's when the format was patent-encumbered just as H.264 is today; the browser barely would have gotten off the ground. In that instance, pragmatism and the need to not break the web won out over a desire to only support free and open formats.

Don't Break the Web

Team Mozilla: I understand your desire to show support for free and open formats and I empathize with your belief that the best way to advance the web is to truly embrace those formats. But I wish this fight was one in which you'd lay down your sword. I disagree that "being idealists" is your reason for being. I believe that your first responsibility as a browser vendor is to make the web a better place; it's certainly what you've strived to do since your inception. But honestly, from the view of a realist, the only thing you're going to accomplish is making the HTML5 <video> tag unusable.

Two Proprietary formats

What's worse, you'll force people to continue to use Flash as the preferred delivery platform for video on the web (which, as covered above, already uses H.264 for video). Instead of one proprietary format, people will now be forced to use two simply because of your refusal to accept that sometimes you have to take a few small steps to get to your goal. I hope you can at least agree that going from two proprietary formats to one is a marked improvement.

Please...

...don't do this to one of the most exciting and promising technologies being delivered in HTML5. You're voluntarily creating another format war and the only result of format wars is people avoid both alternatives because it's too much work to support both. Help us continue to make the Web a better place and move it forward one step at a time; even if those steps aren't quite as long as you'd hoped they'd be.

Update (8:20 am EDT)

I've created a response post that addresses some of the points in the comments titled Mozilla's Not Non-Profit (and Other Thoughts). Thanks to everyone who read this and considered its content and has an opinion to share. Disagreement builds great conversation!

Update (March 22)

I've written a follow-up piece about browsers supporting Theora and my belief that despite the its shortcomings, it has a real place in the future of the Web. Please check out Dear MSFT and AAPL, Embrace Theora!

  

JavaScript Event & Event Method Bugs and Workarounds

May 14th, 2008

Today I spent a good deal of my time dealing with Javascript event handling and delegation using the Prototype javascript library with relation to some forms in our current project. In addition to simply firing and catching events using actual events, this applications also make use of the click() and focus() methods to fire these events in certain circumstances without user interaction. The issues I'm discussing here are specific to radio buttons and checkboxes across the three major browsers--but primarily focused on Firefox and Safari. The provided example does not use Prototype--it is plain vanilla Javascript. However, the proposed workaround does rely on the Prototype library (sorry, it was just faster that way--and it's also the implementation I used to solve the problem on my own).

What (I believe) the spec calls for:

When a radio button or checkbox is clicked with the mouse, the mouse click event will fire with it's target object set to the radio button that was clicked. The radio button will also gain focus.

Both Internet Explorer and Firefox exhibit this behavior exactly (on true user clicks--we'll get to the event simulation methods shortly). Safari, however, only fires the click event. The checkbox or radio button that was clicked does not receive focus as it should.

So let's just always observe clicks and leave focus to the birds

I told you we'd get back to the event simulation methods in a minute. Both Firefox and Internet Explorer exhibit some strange behavior when using these methods vs. actual events. In Firefox, the click() method generates an event with the target set to the calling element--not the actual target of the click. This is inconsistent with both Firefox's focus() method and Internet Exlorer and Safari's handling of both the click() and focus() methods. This example (Firefox, Safari, and Opera compatible) demonstrates the issue.

So where does the problem start?

In the case when you need to force a particular radio button to be selected by default and you have additional Javascript logic that must run based on that selection. Let's say you have 4 radio buttons as in the previous example and you wish the 3rd radio button to be selected by default (we'll assume there's some Javascript logic that must happen based on the user's selection that must also occur with the default selection). Because the user will not be interacting with the default selection, we must rely on event methods to fire our events. So we have some challenges:

  • If we use click() and have our radio buttons listen for a click, Firefox will believe the target of the event is document. The radio button will be selected, but any additional logic based on knowing what was clicked (using event.target) will fail.
  • If we use focus() and have our radio buttons listen for focus, Safari will see the radio button receive focus correctly when the page loads as we will be using focus(). However, any actual user interaction will fail as the focus() event will not fire.

A workaround

I intend to open a bug in the Firefox bug tracker for this issue (if one is not already open; I didn't find one with a quick glance through Bugzilla). Until then, I've written a little workaround that requires the Prototype library to function.

First, ensure that your radio buttons are set up to respond to focus events (since we know that Firefox will only react properly to those events when called programmatically.

$('my-form').getInputs("radio").invoke('observe', 'focus', eventHandler);

Now, observe for clicks to forward on:

$('my-form').getInputs("radio").invoke('observe', 'click', fakeClick);

Your fakeClick method should look like this:

fakeClick: function(e){
   var el = e.element();
   if(el.identify) { /* Filter out click() for FireFox */
      if(this.focused.identify() != el.identify()) {
         e.element.focus(); /* Throws the proper focus() for Safari */
      }
   }
}

The other aspect of this is that within your actual event handler, you need to be sure to set the this.focused to the element that currently has focus.

I've created an example Prototype-enabled JS class to show how the functionality works.

Conclusion

So there you have it, some basic information about a bug in Firefox and a bug in Safari that together make for some interesting times when handling events; and a workaround which I hope you will find useful in getting around these two bugs. Please note that the code is more of an example on how to implement it; though it can be copied verbatim if you wish.

Download ClickFix.js (2kb)

Update 5/14/2009: By pure coincidence, I've added to this post exactly 1 year to the day after I first wrote it. Please see a new post on a Workaround for form submit events not firing with the submit method.