Firefox 6 is here

Download Firefox 6

What’s new in Firefox 6?

The most notable addition to this new release are the <progress> element, touch events, Server-Sent Events as well as the return of WebSockets.

The <progress> element

This element can be used to give a visual cue of something in progress in the page. System progress bars are being used, which means that users of MacOS and Linux will see something different than what is pictured here.

Touch events

The standard Touch events are now available on both Firefox “desktop” and mobile, enabling users to interact with web pages using their fingers on a touch screen.

Try this minimalistic touch demo.

Server Sent Events

Server Sent Events are a mean for a server-side script to generate client-side events accompanied with data.

Messages generated on the server-side with a text/event-stream mime-type and consist of a list of events data.

data: data generated by the server

data: this line will generate a second event

Have a look at the Twitter-like timeline built with server-sent events.

WebSockets are back!

WebSockets can be used to create an interactive communication channel between a browser and a server. They are already used to build “HTML5” chats, multiplayer games, and much much more.
Note that this API will be temporarily namespaced in prevision of upcoming changes to the specification.

Other changes

HTML

The HTML5 <a href="https://developer.mozilla.org/en/HTML/Element/progress"><progress></a> element, which lets you create a progress bar, is now supported.
The parsing of the HTML5 <a href="https://developer.mozilla.org/en/HTML/Element/track"><track></a> element, which specifies text tracks for media elements, is now supported. This element should appear in the DOM now, though its behavior is still not implemented.
The <a href="https://developer.mozilla.org/en/HTML/Element/iframe"><iframe></a> element is now clipped correctly by its container when the container’s corners have been rounded using the <a href="https://developer.mozilla.org/en/CSS/border-radius">border-radius</a> property.
<a href="https://developer.mozilla.org/en/HTML/Element/form"><form></a> elements’ text <a href="https://developer.mozilla.org/en/HTML/Element/input"><input></a> fields no longer support the XUL <a href="https://developer.mozilla.org/en/XUL/Property/maxwidth">maxwidth</a> property; this was never intentional, and is in violation of the HTML specification. You should instead use the <a href="https://developer.mozilla.org/en/HTML/Element/input#attr-size">size</a> attribute to set the maximum width of input fields.
The <a href="https://developer.mozilla.org/en/HTML/Element/canvas"><canvas></a> <a href="https://developer.mozilla.org/en/DOM/CanvasRenderingContext2d">CanvasRenderingContext2d</a> properties fillStyle and strokeStyle used to ignore garbage included after a valid color definition; now this is correctly treated as an error. For example, “red blue” as a color used to be treated as “red”, when it should have been ignored.
The width and height of <a href="https://developer.mozilla.org/en/HTML/Element/canvas"><canvas></a> elements can now properly be set to 0px; previously, these were getting arbitrarily set to 300px when you tried to do that.
When a <a href="https://developer.mozilla.org/en/HTML/Element/textarea"><textarea></a> element receives focus, the text insertion point is now placed, by default, at the beginning of the text rather than at the end. This makes Firefox’s behavior consistent with other browsers.

CSS

<a href="https://developer.mozilla.org/en/CSS/text-decoration-color">-moz-text-decoration-color</a>: This new property lets you set the color used by text decorations, such as underlines, overlines, and strikethroughs.
<a href="https://developer.mozilla.org/en/CSS/text-decoration-line">-moz-text-decoration-line</a>: This new property lets you set the kind of text decorations added to an element.
<a href="https://developer.mozilla.org/en/CSS/text-decoration-style">-moz-text-decoration-style</a>: This new property lets you set the style of text decorations, such as underlines, overlines, and strikethroughs. Styles include single-strokes, double strokes, wavy lines, dotted lines, and so forth.
<a href="https://developer.mozilla.org/en/CSS/hyphens">-moz-hyphens</a>: This new property lets you control how hyphenation of words during line wrapping is handled.
<a href="https://developer.mozilla.org/en/CSS/orient">-moz-orient</a>: A new (currently Mozilla-specific) property which lets you control the vertical or horizontal orientation of certain elements (particularly <a href="https://developer.mozilla.org/en/HTML/Element/progress"><progress></a>).
<a href="https://developer.mozilla.org/en/CSS/%3a%3a-moz-progress-bar">::-moz-progress-bar</a>: A Mozilla-specific pseudo-element that lets you style the area of an <a href="https://developer.mozilla.org/en/HTML/Element/progress"><progress></a> element representing the completed portion of a task.

Other CSS changes

The <a href="https://developer.mozilla.org/en/CSS/@-moz-document">@-moz-document</a> property has a new regexp() function, which lets you match the document’s URL to a regular expression.
The <a href="https://developer.mozilla.org/en/CSS/azimuth">azimuth</a> CSS property is no longer supported, as we have removed what little code we had for the aural media group. It was never significantly implemented, so it made more sense to remove the crufty implementation for the time being rather than try to patch it up.
In the past, the <a href="https://developer.mozilla.org/en/CSS/%3ahover">:hover</a> pseudoclass was not applied to class selectors when in quirks mode; for example, .someclass:hover did not work. This quirk has been removed.
The <a href="https://developer.mozilla.org/en/CSS/%3aindeterminate">:indeterminate</a> pseudo-class can be applied to <a href="https://developer.mozilla.org/en/HTML/Element/progress"><progress></a> elements. This is non-standard, but we hope it will be adopted by other browsers, because it will be useful.

DOM

Using media queries from code: You can now test the result of a media query string programmatically using the <a href="https://developer.mozilla.org/en/DOM/window.matchMedia">window.matchMedia()</a> method and the <a href="https://developer.mozilla.org/en/DOM/MediaQueryList">MediaQueryList</a> interface.
Touch events: Firefox 6 adds support for W3C standard touch events; these make it easy to interpret one or more touches at a time on touch-sensitive surfaces such as touch screens and trackpads.
Server-sent events: Server-sent events make it possible for a web application to ask a server to send events just like any locally-created DOM event.

navigator.securityPolicy, which has returned an empty string for a long time, has been removed outright.
<a href="https://developer.mozilla.org/en/DOM/BlobBuilder">BlobBuilder</a> is now implemented, although for now it’s prefixed (so you need to use MozBlobBuilder).
The <a href="https://developer.mozilla.org/en/DOM/document.height">document.height</a> and <a href="https://developer.mozilla.org/en/DOM/document.width">document.width</a> have been removed. bug 585877
The <a href="https://developer.mozilla.org/en/DOM/DocumentType">DocumentType</a> object’s entities and notations properties, which were never implemented and always returned null, have been removed, since they’ve been removed from the specification anyway.
The DOMConfiguration interface and the document.domConfig property that used it have both been removed; they were never supported and have since been removed from the DOM specification.
The hashchange event now correctly includes the newURL and oldURL fields.
The <a href="https://developer.mozilla.org/en/DOM/FileReader">FileReader</a> interface’s abort() method now throws an exception when used if no file read is in progress.
The <a href="https://developer.mozilla.org/en/DOM/window.postMessage">window.postMessage()</a> method now uses the structured clone algorithm to let you pass JavaScript objects instead of just strings from one window to another.
The <a href="https://developer.mozilla.org/en/DOM/window.history">window.history</a> API now uses the structured clone algorithm to serialize the objects you pass to the pushState() and replaceState() methods; this lets you use more complex objects (including those that contain cyclic graphs of references).
You can now detect when printing has been initiated and has completed by listening for the new beforeprint and afterprint events.
The document.strictErrorChecking property has been removed, since it was never implemented and was removed from the DOM specification.
The standard <a href="https://developer.mozilla.org/en/DOM/event.defaultPrevented">event.defaultPrevented</a> property is now supported; you should use this instead of the non-standard getPreventdefault() method to detect whether or not <a href="https://developer.mozilla.org/en/DOM/event.preventDefault">event.preventDefault()</a> was called on the event.
The <a href="https://developer.mozilla.org/en/DOM/window.top">window.top</a> property is now properly read only.
DOM views, which we never documented, have been removed. This was a bit of implementation detail that was unnecessarily complicating things, so we got rid of it. If you notice this change, you’re probably doing something wrong.
The EventTarget function addEventListener()‘s useCapture parameter is now optional, as it is in WebKit (and as per the latest version of the specification).
The mozResponseArrayBuffer property of the XMLHttpRequest object has been replaced with the responseType and response properties.
The <a href="https://developer.mozilla.org/en/DOM/element.dataset">element.dataset</a> property has been added to the HTMLElement interface allowing access to the data-* global attributes of an element.
The <a href="https://developer.mozilla.org/en/DOM/customEvent">customEvent</a> method has been implemented. (see bug 427537 )
For security reasons, data: and javascript: URIs no longer inherit the security context of the current page when the user enters them in the location bar; instead, a new, empty, security context is created. This means that script loaded by entering javascript: URIs in the location bar no longer has access to DOM methods and the like, for example. These URIs continue to work as before when used by script, however.

JavaScript

In the past, it was possible to use the new operator on several built-in functions (eval, parseInt, Date.parse…) that should not have allowed it, according to the specification. This behavior is no longer supported. Using the new operator in this way was never officially supported and was not widely done, so it’s unlikely that this change affects you.
ECMAScript Harmony WeakMaps have been added as a prototype implementation.

SVG

The <a href="https://developer.mozilla.org/en/SVG/Attribute/pathLength">pathLength</a> attribute is now supported.
SVG patterns, gradients, and filters now work correctly when loaded from data: URLs.

MathML

The implementation of <a href="https://developer.mozilla.org/en/MathML/Element/mstyle"><mstyle></a> has been corrected.

Accessibility (ARIA)

A state change event is now correctly sent when the value of aria-busy changes.
An attribute change event is now correctly sent when aria-sort occurs.

Net

WebSockets: WebSockets was updated to protocol version 07 for Firefox 6.

Parsing of the Content-Disposition header has been fixed to properly interpret backslash-escaped ASCII characters as just that character itself. Previously it was incorrectly replacing that character with an underscore (“_”).
The value of the path field on Set-Cookie headers is now interpreted correctly when quotes are used; previously, they were being treated as part of the path string instead of as delimiters. This change may affect compatibility with some web sites, so authors should check their code.
The Upgrade request header is now supported; you can request an upgrade of an HTTP channel to another protocol by calling <a href="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIHttpChannelInternal#HTTPUpgrade%28%29">nsIHttpChannelInternal.HTTPUpgrade()</a> .

Other changes

Support for microsummaries has been removed; these were never widely used, were not very discoverable, and continuing to support them was making improvements to the Places (bookmark and history) architecture difficult.
WebGL now supports the OES_texture_float extension.

You can help us improve those changelogs by telling if you find the level of details appropriate.

Developer Relations Team, long time jQuery contributor and Open Web enthusiast. @louis_remi

twitter.com/louis_remi

91 comments

Sasha

Touch events are nice touch :)

On the serious note, hats off to you guys, it appears that you are working like maniacs lately cranking out all those features.

August 16th, 2011 at 08:51
Johnny Simpson

Wonderful work guys. I’m glad to see you still pushing standards forward :)

August 16th, 2011 at 08:58
Luis Elizondo

Not enough changes for a mayor version release. I don’t want to be using Firefox 3569 next year!

August 16th, 2011 at 09:16
1. louisremi
  
  We’ve changed our release cycles: http://hacks.mozilla.org/2011/04/aurora/
  Version numbers are just numbers, what matters is that we deliver features faster to you, Firefox users and Web developers.
  
  August 17th, 2011 at 00:37
  1. Jose
    
    Considering that “just numbers” break extensions and make it just plain difficult for admins…
    
    August 17th, 2011 at 04:16
    1. Alex
      
      Couldn’t agree more, Jose. Another new version…half my extensions no longer work. What’s the point? Using Firefox is no longer ‘fun’.
      
      And, rapid updates is one of the reasons why Chrome is unsupported at work…now Firefox? You’re pretty much pushing companies back to IE. Heck, we’re still on IE8 at work, probably won’t go to IE9 until next year. Whether it’s right or wrong, companies move at a slower pace, because they need to continuously support the internal software that keeps the place going. These rapid changes just mean that Firefox won’t be supported anymore. The extensions we need for day to day work keep breaking every few weeks now. It’s not good.
      
      August 17th, 2011 at 06:19
      1. Paul
        
        This is absolutely true! While the developers building Firefox may see the WHOLE world in Firefox glasses, actually the rest of the world have a job to do that isn’t Firefox, and that world needs a stable, predictable platform to work with. Progress is good, but it must occur in a manner that facilitates absorption.
        
        When Norton Internet Security and other plugins break because of version numbers and other changes, and I’m left for weeks waiting for catchup’s the whole ‘speed’ issue feels very grubby, rather than just proactive and innovative.
        
        Firefox is still good, but serious Mozilla, I don’t stay awake nights waiting for the next release. I’m happy to get the next release when it’s fully baked.
        
        August 17th, 2011 at 15:59
      2. Johann Mahne
        
        I agree with Paul Alex and Jose.
        Fire Fox no longer works with ClickOnce deployment.
        My add-ons don’t work anymore either.
        
        August 18th, 2011 at 02:29
      3. Daniel Veditz
        
        Only a small fraction of the add-ons hosted on AMO are incompatible. It would really (really!) help if the people complaining their add-ons were incompatible would tell us which ones so we know which developers we need to reach out to and work with.
        
        August 18th, 2011 at 12:47
      4. Candace
        
        I like Firefox 3.6.11. I don’t really want updates. I keep downloading 3.6.11 that I have on file and it goes up to 3.6.23 again. I wonder how I can stop this? Your reasoning is good. I really like IE7, and they moved me up to IE8 and it was and is still crappy on my computer, I learned you have to keep it, because that’s what my computer comes with or something. I tried Firefox 4.0 and I could not seem to find how to do the things I did on 3.6; such as, the fast cutting and pasteing I like to do to social sites. I am sorry to be ignorant about computers, but when I get what I am happy with, progress screws it up. Nice if you are a computer whiz, not so nice when you are not. Thanks.
        
        October 10th, 2011 at 00:00
    2. Logan
      
      I agree, this new versioning is ridiculous. If they’re just numbers, what’s wrong with “just numbering” them 4.1 and 4.2? Save the whole versions for releases that are actually a big deal.
      
      August 17th, 2011 at 06:45
    3. austin
      
      i have to agree the version numbering is going too high too fast, and soon you will be at very large numbers that start to get ridiculous (as his “firefox 3569” alludes to) people can handle small numbers even weird decimals(i say weird because 3.5.26 is not a real decimal but kinda looks like one. its made of a series of small numbers that are easy on the eye)
      
      August 17th, 2011 at 07:05
      1. Luis Elizondo
        
        This is already ridiculous. This change to the release cycle is one of the stupidest decisions I’ve ever seen in an Open Source Project. What are you trying to achieve Mozilla? Really. You’re breaking extensions every two months or less, you’re making it really hard for developers to keep up to date with your changes, and remember, those developers are working for free, on their free time. Remember the expectation of Firefox 3 and Firefox 4? Millions of downloads in hours, even a Guinness World Record, and now with 5 and 6 you’re just loosing momentum against other browsers, when will you get another ‘Firefox party’ to celebrate the next release of the “Greatest Browser Ever”? When you reach Firefox 1000? Or maybe Firefox 2000? Again, this is stupid. You can still make really fast updates without moving to a major version and making big efforts to not break extensions.
        
        I will still use Firefox because of Firebug, but the moment you break it with one of your “mayor” versions, I’m done with you. There’s no reason to keep using a browser like Firefox when I have other options. This is not year 2000 when we have only two options.
        
        August 17th, 2011 at 07:47
    4. Claude H
      
      This new versioning is just a marketing ploy to make people feel they should be upgrading…
      Like if you have 4.1.1 but the latest version is 4.1.3 or 4.2… then it’s means you probably aren’t missing anything so no need to update… but with those ridiculous versions you get up one morning realizing you are a few dozen major versions behind… so you feel you have an outdated software and rush to the download page to upgrade…
      
      anyway that’s my theory,
      
      absolutely everybody I know thinks this new versioning is retarded
      
      August 17th, 2011 at 15:52
      1. louisremi
        
        We increase major version numbers because we add new features and sometime change APIs in a non-backward compatible way.
        I’m contributing to several Open Source project and this versioning is the usual one.
        
        August 18th, 2011 at 02:49
      2. Benno
        
        There is only _one_ supported version at a time (on the stable channel in the new release model) so updating should be always the answer.
        
        August 20th, 2011 at 08:53
Aldonio

Nice features, but when will we get window.onbeforeunload working like before? or CSS sprites via background-position-x and background-position-y?

August 16th, 2011 at 09:21
1. louisremi
  
  both of those features have never been standardized.
  onbeforeunload was changed to improve the user experience (see bug 588292)
  background-position allows you to specify its position on the x and y axis at the same time.
  
  August 17th, 2011 at 00:42
Kenneth Stein

Really happy to see Websockets back in this release. I’ve implemented my site’s interactive facilities PostJockey.comaccording to a carefully thought out periodic polling strategy, so I’m good and ready to take a look at Websockets! Looking for the day when the ” tag will cleanly support accessing live icecast streams as well. Much thanks and great work! Really appreciate it!

August 16th, 2011 at 10:50
–

Sweet!

August 16th, 2011 at 11:09
Debasis sabat

Mozilla is planning on hiding the version number from normal users by removing it from the ‘About’ box. The new build doesn’t feature any major new user facing feature. This is of course the side-effect of following a rapid release cycle. the biggest piece of new feature is that the address bar now highlights the domain of the website you are currently browsing.

August 16th, 2011 at 11:44
1. Andy M
  
  Even that feature is broken somewhat. I’m currently at hacks.mozilla.org but only mozilla.org is highlighted. To me that does not seem right and to a new user the WHOLE url should be important. It’s a bit like telling someone where you are over the phone … hi .. I’m in New York (where in NY?) ummm…. New York!
  
  Perhaps there’s a perfectly good reason to highlight the domain, but I fail to see it.
  
  August 17th, 2011 at 23:59
  1. Benno
    
    Subdomains play a much lesser role and on top of that might be user-controlled
    
    August 20th, 2011 at 08:51
Jake

“You can help us improve those changelogs by telling if you find the level of details appropriate.”

Yep, this is a step in the right direction.

August 16th, 2011 at 12:33
1. louisremi
  
  Thanks for the feedback Jake,
  have you got another recommendation?
  
  August 17th, 2011 at 00:44
2. Johan Sundström
  
  Seconded! Also, you’re doing a really great job of responding to sound questions here, louisremi, wherever scope allows. The bookmarklets description was, while not what I had hoped to hear factually, the an excellent tech summary of everything important, for instance.
  
  You may at some point want to write a post on why you opted for bumping majors each releas, as it looks a bit like arbitrary copying some big brother decision of Chrome’s on the hope that they probably had some good reason that might apply to you too. (My only real guess is an eagerness to break through v10 soon and more or less force userAgent sniffers to stop using regexps and start using code sooner. This question hasn’t been answered by mozilla officially anywhere, for all I know, but I am sure you have some reason.)
  
  The quickly-spinning-away version numbers have led at least me to stop using maxVersion in extension manifests not published through AMO, by setting it at a fix 4711.*, hoping that should be good through 2283AD and dealing with breakages reactively as they are discovered instead. I think I would not have picked the next major.*, had you sticked to keeping the major numbers reserved for “there’s been significant internal turmoil from last release”, the way it’s been until now, and just spinning away at the minor version level most of the time.
  
  August 18th, 2011 at 15:59
  1. louisremi
    
    Contrary to persistent and very creative rumors, we do not have “secret reasons” or “hidden plans” driving our release cycle and numbering strategy ;-)
    I’ll quote myself: “We increase major version numbers because we add new features and sometime change APIs in a non-backward compatible way.
    I’m contributing to several Open Source projects and this version numbering is the usual one.”
    We know this cause problems and we are actively searching for solutions to solve them.
    
    August 19th, 2011 at 08:02
    1. Johan Sundström
      
      When public statements don’t make any sense to people, and when they contradict each other, people resort to guessing your motives; I don’t think that will ever change unless they get conveyed way more understandably and seemingly less self-contradictorily.
      
      Your response above is a good example of what seems like self-contradiction to others, in that you suddenly decided to, from now, _always_ increase major numbers, because you _sometimes_ change APIs in non-backwards-compatible ways.
      
      Common open source projects tend to bump major versions for backwards-compatibility-breaking updates and minors for non-backwards-compatibility-breaking changes (or, maybe more typically still, use a major.minor.build scheme, reserving majors for “we’ve added a shit-load of new features”, minors for “compat breaking changes” and only bump build numbers when upgrading only fixes bugs and similar without breaking anything external).
      
      The only other well-known open source project I know of which releases every three weeks and bumps major versions each time is Google Chrome, hence guesses that it’s the one precedent you aspire to copy, for reasons not yet commonly understood outside of the mozilla organization. I don’t think it’s for lack of wanting to understand; on the contrary, people try hard to make sense where they see none.
      
      Again speculation, but another one that would make some kind of sense at least to me is “as Firefox’s extension API essentially is not an API but exposing all its innards to poking and tweaking, all change in Firefox has equal opportunity to break extensions, and so all new releases should be major version bumps, to be honest about how the new release can affect third-party add-ons”. That’s both the strength, beauty and weakness of it (=add-ons can test out major UI and functionality changes that no other browser can – at the cost of being more brittle to firefox changes), and of course not what users want to hear.
      
      If it turns out to be the real reason, though, it would make people stop speculating so much, were it shared by someone speaking for the organization. Every information void gets filled with some content, and you’re at choice about whether it’s a lot of conspiracy theories and bull shit, or your own reasons. And if you’ve already done all you can to share all those reasons, and people still don’t understand them or buy them, maybe they don’t make sense and policy should be changed to some scheme that does?
      
      I’m not so much criticizing choices above, as simply noting that I as an add-ons author don’t understand how the version numbering policy is good, or what merits Mozilla saw in it to choose it, that I would love to know, and that I feel it hasn’t been spoken of in the Mozilla blogs with the kind of astonishing clarity you achieved in your description of the javascript: security policy change, which had hitherto been a similar void of missing or jumbled information.
      
      I appreciate your communication style and hope you’ll speak more for Firefox on similar matters to stave off confusion, where there currently is a great deal of it. So the main feed-back is that this is one of those areas. Despite all efforts so far, strong or weak.
      
      August 19th, 2011 at 12:54
      1. Benno
        
        Deciding what … for a major version bump and what not might be arbitrary and subjective. On top of that patches might get backed out before they reach the stable channel. Then again there would need to be discussion whether the major version bump should be changed into a minor, too much hassle considering also, that version numbers loose their meaning when there is only _one_ supported version.
        
        August 20th, 2011 at 08:43
Jose

Thank you for breaking my extensions once again. Whats up with the number jumps????

August 16th, 2011 at 14:22
1. Luis Elizondo
  
  Ohh, don’t worry, developers will fix them just about a week before they launch Firefox 7 and the history will continue.
  
  August 17th, 2011 at 07:51
Lkz

Yes, that is a great example of a changelog. Way more useful than what you find on le regular Firefox page typically.

August 16th, 2011 at 14:25
Mircea Eliade

Guess Navigation Timing is up for Firefox 7..

August 16th, 2011 at 15:22
1. louisremi
  
  You’re right, see teh Aurora 7 blog post.
  
  August 17th, 2011 at 00:46
Style Thing

no microsummaries… thanks. sticking with Firefox 5

August 16th, 2011 at 17:48
1. TacoMan64
  
  You actually use microsummaries? For what?
  
  August 17th, 2011 at 10:14
  1. Style Thing
    
    With Microsummaries Generator Builder it’s actually pretty handy.
    I’m using it for showing the last news in my local news site and for torrents to look if there’s an update for some show and new episode is available for download.
    
    August 19th, 2011 at 11:25
2. Benno
  
  Bad idea, there are unfixed security vulnerabilities.
  
  August 20th, 2011 at 08:44
  1. Style Thing
    
    May be, but what can I do – I can’t take away the title from the half of my bookmarks on the bookmark panel :(
    
    August 24th, 2011 at 09:00
Ricardo

Won’t the new security context for javascript: URIs break most bookmarklets?

August 16th, 2011 at 19:29
1. louisremi
  
  Good question, here’s the answer:
  
  you can’t just click on a bookmarklet inside a Web page (no DOM)
  you can’t type a javascript bookmarklet right in your URL address (no DOM)
  you CAN bookmark a bookmarklet and execute it from your bookmark bar or menu
  
  August 17th, 2011 at 00:53
Ali

Is there any plan for implementing the HTML5 ruby tag?

August 16th, 2011 at 23:38
1. louisremi
  
  You can follow the status of the implementation of the ruby tag on the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=33339
  
  August 17th, 2011 at 00:58
Andy M

I don’t mind the new features but why does each new version have to break so many plugins and add-ons?

It’s damn annoying to lose functionality that works perfectly well, just because a few new features have been added.

August 17th, 2011 at 06:53
Oli

Aurora user, but keepign up to date.

Nice to see you guys not putting on the breaks,
I didn’t know about websockets.. *goes to have a play*

August 17th, 2011 at 07:07
Mike Wilcox

Great work, but it would be nice to see some attention paid to the buggy plugins like Flash and Quicktime.

August 17th, 2011 at 07:15
1. louisremi
  
  We make our best to prevent these plugins to crash Firefox when THEY crash.
  But we cannot fix those third party extensions ;-)
  
  August 18th, 2011 at 02:57
Haider

Why doesnt firefox still save the pages by the title tag ?

August 17th, 2011 at 07:44
1. louisremi
  
  This seems to be a complex problem, we have a bug report for it: https://bugzilla.mozilla.org/show_bug.cgi?id=115176
  
  August 17th, 2011 at 08:06
raj

version no’s can be 1 thru 100000. by the time we reach 1000 the product itself will become obsolete. we dont have netscape anymore right. same way. of couse firefox is the new avatar of netscape. so by the time firefox reaches 1000 it will be rechristined firebox LOL

August 17th, 2011 at 08:32
Haider

I cant understand why this is such a complex problem when simple extensions provides this feature

August 17th, 2011 at 08:32
Brijan

Really nice list of additions and improvements over there !

I’ve got to try the touch event on my device .

August 17th, 2011 at 10:03
Joe Luhman

Thank you for breaking my extensions for the second time in as many months. How long is this insanity going to continue? Please stop breaking the extensions for every major release, or please re-think this silly move to a six week ‘major’ release cycle.

August 17th, 2011 at 10:07
Ted

I’m going to skip 6 and wait until next month when 7 comes out.

Better yet, I am going back to 3.6.x on the computers I have 5 on now. It’s a noticeable upgrade to 4, 5, and 6…

August 17th, 2011 at 11:08
Pierre Boucher

As I am reading the comments, I can only come to the conclusion that those answering from Mozilla do not comment at all regarding the new numbering scheme with all the extensions compatibility problems that might results from it.

Is it that nobody at Mozilla cares any more about their loyal user base? I’ll be scanning those comments again and if I cannot see any change of attitude from you guys, I am moving to an other browser. It will hurt a bit because I was an early adopter of this fantastic browser that was Firefox in the time when stability was still considered important.

August 17th, 2011 at 11:53
1. louisremi
  
  This is an important problem, be sure that we are all well aware of it (Mozilla employees are all Firefox users and addons addicts).
  I’ll try to explain once more our decisions in a comment below.
  
  August 18th, 2011 at 03:05
Hans

As a developer and IT manager I have been a loyal Firefox user for many years. I have also spent a lot of effort convincing people at my company that we should all be using Firefox with a carefully selected set of plugins to enhance functionality and simplify various tasks. However, the recent changes, starting with FF 5.0, causing several important plugins to break (and lack of the Google toolbar) are starting to give me headaches. Imagine having to research why things broke, then try to fix them with “Incompatibility support”, and having to do that on numerous PC’s… support nightmare! If only Chrome would have support for plugins… or maybe I should consider switching back to IE!? Please mozila guys… don’t make us consider that!!

August 17th, 2011 at 11:55
Scott

It is quite evident that Mozilla has hired an egotistical, moronic, imbecile that previously worked for Microsoft and was terminated for his or her consistent egomania that discomfited consumers.

Oh sure, Microsoft still has some of them on board, but it is apparent that the worst offender of this disregard to customer satisfaction has gone from working for Microsoft and is not employed by Mozilla.

Why else would Mozilla adopt such an idiotic versioning policy that makes using Firefox and developing extensions for Firefox harder than it has to be.

At this point, I will be staying with Firefox 5 and remain with it for the duration as I consider whether or not to discontinue the use of Firefox altogether.

At this point, we might as well start calling it FireFlops as every new version causes installed extensions to flop.

August 17th, 2011 at 12:40
Jason

Websockets and Server Sent Events are the 2 most important things I see out of that list as both of those can really change how apps interact now in Firefox, with more options in how the client can interact with the server.

I’m definitely looking forward to more of the html5 javascript apis, and css3 options coming in, as it gives us a lot more to play with.

August 17th, 2011 at 12:52
Pierre Boucher

I can’t believe that my last post was not published just because I mentioned the absence of answers from the Mozilla people to the versionning issues mentioned by other users.

Hopefully this one will get published.

August 17th, 2011 at 15:28
1. louisremi
  
  I’m in charge of moderating comments on this page and I work only 8 hours a day, maybe in a different timezone.
  
  August 18th, 2011 at 03:08
  1. Pierre Boucher
    
    @louisremi Sorry for the comment, this one could have been dropped. Like I said in a second reply to myself, it must be a bug with the site because as I checked to see if my comment was accepted, it was not there anymore.
    
    August 18th, 2011 at 05:55
Luis Elizondo

Some one needs to stop this fast release madness. Certainly http://hacks.mozilla.org/2011/08/firefox6/comment-page-1/#comment-769639 is not the effect that we all want.

August 17th, 2011 at 16:03
Fred The Kat

Great stuff. In an ideal world, MS would kill IE and look at a career in fast food management.

August 17th, 2011 at 16:08
art

plugin-container.exe has encountered a problem and needs to close. We are sorry for the inconvenience.

Error signature
AppName: plugin-container.exe AppVer: 6.0.0.4240 ModName: nspr4.dll
ModVer: 4.8.9.0 Offset: 000092ac

The following files will be included in this error report:
C:DOCUME~1ADMINI~1.PUHLOCALS~1Tempf709_appcompat.txt

August 17th, 2011 at 19:53
KFGD63

Nice features folks.
Does the incompatibility of version 5.0 with google page rank fixed or….?

August 18th, 2011 at 00:21
David

I think that if we are looking at a faster release cycle then the method of validating add ons needs to be looked at. Perhaps addons can request version numbers of only the features that they rely on?

I’m not seeing a response to the concern that add ons are struggling with this release cycle, do you have any thoughts on how we can reduce add on obsolescence?

August 18th, 2011 at 01:46
Insano

Sadly, I see the same kind of comments everywhere where Firefox 6 is announced. I wonder when Mozilla will wake up and noticed that people are not happy with this new release cycle and that the market share will just continue to shrink.

It seems like the attitude is “yeah, we know, and we are working on this”. But why then even start with this new release cycle if you didn’t solve all the issues first? It might be too late once all these annoyances are fixed.

@louisremi

Please spend some times reading the news regarding this new release. It shouldn’t take you long to realize that people are not happy with this. Saying that other projects do this as well shows me that you are not really understanding how much damage Mozilla is doing to itself.

August 18th, 2011 at 03:05
Neil Rashbrook

I can’t find anything suggesting that input used to honor a maxwidth property or attribute. Could you point me to a bug number?

By the way, the restriction on javascript: looks like it belongs in Other rather than DOM, since it’s not related to the DOM.

August 18th, 2011 at 04:17
………..

https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible

They are planning to make extensions compatible by default in Fx 9.

August 18th, 2011 at 07:10
1. Steve
  
  While that is indeed good news, it’s something that should be implemented *far* sooner – in 6.0.1 for example. Or 7.
  
  August 18th, 2011 at 16:53
Cynyster

Will Firefox 7 have native support for 64bit Operating systems?
Just out of curiosity was Mozilla’s idea of ramping up the version numbers to coincide with the Microsoft windows version number (windows 7 firefox 7…)
And how and when is HTML 5 being integrated into Firefox?

August 19th, 2011 at 01:54
1. louisremi
  
  Firefox 7 is indeed supported by 64bit Operating Systems. We won’t have 64bit builds of Firefox available, though.
  During Windows 7 lifespan, we will release numerous updates of Firefox (we won’t wait for Windows 8 to release Firefox 8)
  HTML5 is “under construction” and gradually supported in Firefox.
  
  August 19th, 2011 at 07:50
Eric

Calling each merge every 6 weeks a major update and giving it a new version number seems crazy and annoying. Firefox 5 added nothing and Firefox 6 added almost nothing. Why is Mozilla trying to be the one organization that diverges from the standard 4.1, 4.2, etc release pattern?

August 19th, 2011 at 10:14
Jeremy

Come on guys, the problem here is not that the devs ship too fast. Go back to the old release cycle would be stupid. The problem is that the plugins breaks everytime there’s a new major change, even though they might not be affected by it. The fast release cycle is showing us that the versioning system for the plugins is the bottleneck here. Let them fix that and all will be good.

I don’t know what kind of plugin you guys use, but I’m always able to find a beta version my plugins that works.

August 19th, 2011 at 14:34
Paul

Louis, thanks for at least reading these messages, and thanks again for the great work on Firefox to-date. Firefox is a great browser.

Like many others on here I do have a big problem with release numbers, please understand that while your other open-source projects may increment the major release number, you’re missing a big point with the numbering scheme and I believe you’re dismissing something important here.

Many people do not release MAJOR releases to a production environment until they become stable, for example a serious business is CRAZY to release version 6.0 throughout their business! The tech-guys of course WILL install 6.0 to test it, in a contained safe non-production environment, and see what new features are there.

If Firefox abandons minor release numbers, how do I know when we have a stable patched release suitable for business, or when we have a bleeding-edge major release not-yet suitable for business? I DON’T KNOW! I really do not want to put a major release into production.

Chrome is getting market-share because they are Google, and people just want to explore – I’m sure the attraction isn’t their major release number policy!

How about we compromise? Call the next release Firefox Infinity 6.1? (Unless of course you really do change backward compatibility).

Firefox is still the best browser. :)

August 19th, 2011 at 15:45
1. louisremi
  We have strict Quality Assurance planning which includes 3 Months of tests by “beta testers” before releasing Firefox to the public.
  There are two testing phases: Aurora and Beta which are at least six weeks long each.
  We cannot, however, guarantee that third party addons will all be compatible when we release a new version, but we are working hard to reduce the number of incompatible addons by:
  - providing a stable addons SDK
  - getting in touch with authors of popular addons and helping them keeping their addons up to date
  August 21st, 2011 at 16:01
Cynyster

Pardon me.. I am not trying to split hairs here. But to me “Naitive support” means it will BE a 64bit program not a 32 bit. By saying it will be supported.. means to me that its is a 32 bit program which is to say its not a 16 bit program which wont run on a windows 64bit platform.

So back to the question for my clarity sake.

Is Firefox 7 a 64 bit application?

August 19th, 2011 at 16:34
1. Benno
  
  There exists an official IA64-bit version for OS X (hybrid PE file) and Linux but not yet Win64.
  
  August 20th, 2011 at 08:46
2. louisremi
  
  “We won’t have 64bit builds of Firefox available” means that Firefox 7 is not a 64 bit application.
  
  August 21st, 2011 at 14:55
isabel

Hola… Soy una persona d 55 años y sin experienza.. ..pero desde q uso este navegador me siento muy segura d como sequir dando los pasos correctos….
gracias x enseñar y ayudar ….

August 20th, 2011 at 07:21
Matthew Bonner

Why is “incompatibility” missing from the list of features? I filed numerous bug reports regarding the version numbers which the developers appeared to laugh off.

I therefore resign from contributing to Firefox, I was the person who fixed the tabs so they could be themed, I created the original Lunar theme and I have submitted bug reports regarding security vulnerabilities and buffer overflows.

Mozilla is not just losing users with this change, also people like myself. I am switching to Chromium as of today:
http://www.chromium.org/

August 21st, 2011 at 13:29
1. louisremi
  
  We are sad to hear that Matthew.
  We are fully aware that the choices we’ve made are difficult ones.
  Some difficulties were foreseable, some weren’t expected.
  Be sure that we are hard at work to solve as much as we can, but this process takes time and involves (sometime harsh) debates.
  We value your contributions and your voice and you will always be welcome in the mozilla community.
  
  August 21st, 2011 at 15:42
2. PaBLoX
  
  What you can do with chromium and firefox are different things; you should try to remember that are other reasons behind technical ones that could drive you to make a decision and I found principles an important one.
  
  I agree with you (and a lot of people more in this debate) that some changes are annoying and a lot of times these make me work more. Mozilla is centered on open web and free/open technologies in a way that not very much companies are.
  
  So at least for me; I rather stay late one more night than walk each day to a closed environment.
  
  August 25th, 2011 at 12:26
steve

Firefox is developed by developers for developers!
Just like a tree bears flowers and fruit for it’s own reproductive sake – if we like the fruits and enjoy eating them, even getting to the extent of hanging around the tree, anticipating each new release …of new fruit, well, that’s just us.

The tree doesnt mind, neither does it care.

Its the same with Firefox. They don’t build it for YOU, they build it for THEM! It is THEIR project and THEY have fun building it!

If YOU enjoy it as well, that’s awfully nice, but also irrelevant.

All this is not a “bad thing” …it’s just “a thing”. The way it is. Like fire being hot, or water being wet, we don’t bemoan those behaviors, we just accept them as being the simple manifestations of the items in question.

August 24th, 2011 at 12:14
PaBLoX

Really people? Most extensions just break because of the number version, so I suggest to pick this addon:

https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter

If the addon doesn’t work just put “This addon no longer works”. Honestly, I’ve been using this for a lot of time and I’ve never ran into a problem that a couple of clicks can’t solve it.

August 25th, 2011 at 12:19
kremlen

I can’t imagine anything driving me away from Firefox; I’ve used it almost my entire computing life and I have dabbled with other browsers and just don’t find them appealing or I don’t agree with the way they close some or all of their code.

But. The addon system, on of the main draws of Firefox in the first place, is broken. If every time Firefox releases a new major version, my addons stop working (and they do; I don’t care what the optimists say; I don’t want to have to report my addons are broken, every 6 weeks, I just want to update and keep working) and all the addon developers have to go and change and re-upload their addon so it continues to work with Firefox — that’s just not going to happen.

So that’s got to be addressed. But until then, I’ll keep happily using Firefox, because it’s still the best.

Oh yeah, it really IS a chore to upgrade so often. In fact, for a large network, I don’t even see how it’s realistic.

August 27th, 2011 at 09:06
the Kid

On behalf of the guys talking ’bout add-on, that’s just great, I won’t be upgrading to Firefox 6 anytime soon..I’d stick on this version I’m using.

On the other hand, scrollable tabs are really cool especially for us guys who like to open multiple tabs, I also like to bookmark a lot of sites..you guessed it “scrollable bookmarks”, can you guys at Mozilla community add this as a feature for upcoming releases and when everyone realizes that Firefox is the greater browser for the web users.

August 31st, 2011 at 22:08
Stomme poes

I’m still using 3.6x because I use plugins for my job. I recently donated to the more important ones I use, to help those developers rewrite their plugins every 6 weeks. Latest 3.6x update killed syntax highlighting on view source, arg.

But what I would like is somewhere I can take my current browser, with its current plugins, and see WHICH ones are supported were I to upgrade to whatever the “latest” Firefox is at that time. This allows me to decide whether I upgrade, or wait. I’ve been waiting because every time I hear people say plugins I use are working, that version is already obsolete.

Is there something at AMO I can use to determine which of my plugins work in which versions? I don’t care if it’s just a numbering issue or it doesn’t work because of an API change. 3.6x is now unsecure, but it still works. Except for that new syntax highlighting bug.

September 1st, 2011 at 02:41
Sid

Very informative article on right time. Understanding browser is a vital required skill for today’s tech professionals.

September 20th, 2011 at 07:52
uod

Web Developer tool? For normal users? Are you people thick or are you just plain trying to annoy us?

February 5th, 2012 at 03:02

Comments are closed for this article.

Hacks

By louisremi

What’s new in Firefox 6?

The <progress> element

Touch events

Server Sent Events

WebSockets are back!

Other changes

HTML

CSS

Other CSS changes

DOM

JavaScript

SVG

MathML

Accessibility (ARIA)

Net

Other changes

About louisremi

91 comments

Firefox 6 is here

By louisremi

What’s new in Firefox 6?

The <progress> element

Touch events

Server Sent Events

WebSockets are back!

Other changes

HTML

CSS

Other CSS changes

DOM

JavaScript

SVG

MathML

Accessibility (ARIA)

Net

Other changes

About louisremi

Discover great resources for web development

Thanks! Please check your inbox to confirm your subscription.