Firefox 4 Beta 9 - a huge pile of awesome - Mozilla Hacks

Hello, and welcome to the post for Firefox 4 beta 9. If you’re reading this then you’re interested in what we’ve got coming down the pipe for the latest beta for the wonderful browser known as Firefox 4. We’re starting to reach the end of our development cycle for the next release of Firefox and I thought it might be worth it to give a full overview of everything that we’ve got in store for web developers vs. Firefox 3.6. So if you’ve read previous releases, some of this will look familiar. But this is a new beta and we’ve been busy, so there’s something new in here for everyone.

Performance

One of Firefox 4’s main themes is Performance. As such, we’ve done a huge amount of work to improve browser performance across the board, from startup time, to JavaScript performance, to interactive performance and making the user interface easier and more efficient to drive. That being said, here are some of the things we’ve done to improve performance up to Beta 9.

The JaegerMonkey has landed.

And you might have noticed that it’s really fast. This is the world’s first third-generation JavaScript engine, using Baseline JIT technology similar to engines found in other browsers and kicked up a level with the Tracing engine found in Firefox 3.6. As such, we’re competitive on benchmarks such as Sunspider and V8, but we’re also fast at a whole mess of things that we expect to see in the set of next-generation web applications, hence Kraken.

Hardware Acceleration

Firefox 4 supports full hardware acceleration on Windows 7 and Windows Vista via a combination of D2D, DX9 and DX10. This allows us to accelerate everything from Canvas drawing to video rendering. Windows XP users will also enjoy hardware acceleration for many operations because we’re using our new Layers infrastructure along with DX9. And, of course, OSX users have excellent OpenGL support, so we’ve got that covered as well.

Compartments

Compartments, added in Beta 7, is infrastructure that we’ve added to Firefox to improve performance, give us a better base for security and, over the long term, give us better responsiveness because of its positive effects on garbage collection. (Note that there are some parts of Compartments that still have not landed.) If you want to learn about why Compartments are so important, have a look at Andreas Gal’s great post on the topic. He does a great job of explaining what they are and how they work.

Improved DOM performance and style resolution

We’ve made a huge number of improvements to our overall DOM and style resolution performance as well. Although JavaScript gets much of the focus these days, it turns out that in page load and interactive performance, the DOM and style resolution (usually as part of reflowing a document) often affect page performance more than JavaScript. And as such we’ve seen improvement across the board in this area with Firefox 4. In some tests we’re a solid 2x faster than Firefox 3.6.

JavaScript typed arrays

If you’re doing processing with JavaScript and you want to process low-level data, Firefox now supports native typed arrays in JavaScript. This can make a gigantic difference in how fast items are processed if you’re doing WebGL or image manipulation.

In addition, if you’re getting data from an XHR request, you can get that data as a JavaScript native typed array for fast processing with mozResponseArrayBuffer.

JavaScript animation scheduling APIs

We now support events that let you schedule animations from JavaScript. Doing this means you aren’t wasting CPU and battery by running your animations as fast as possible when the underlying rendering engine isn’t going to draw them anyway. (Gecko now has an internal timer for all drawing and will render at a maximum of 60fps, the edge of human perception. It will also turn this timer down to 1fps for tabs that aren’t in the foreground. Use it.) This is most useful for people building libraries, but you should be aware that there’s a better way to animate in Gecko.

Retained layers

As mentioned above, Firefox now has an internal Layers system for improved drawing performance for many types of web pages. Images, fixed backgrounds, inline video, etc. are now rendered to an internal layer and then composited with other parts of a web page in a way that can take advantage of hardware acceleration. This improves the page load time and interactive performance of many web pages.

Asynchronous plug-in painting

On Windows and Linux we now paint plug-ins asynchronously. In previous releases when we wanted to paint a web page that included a plug-in, we would have to ask the plug-in for the data to paint. If a plug-in was slow or was hung, it would make the browser feel slow. Now we’re able to get that data asynchronously, which means that the overall responsiveness of the browser should be improved.

Vastly improved cache

Firefox 4 has a vastly improved disk cache. This disk cache should result in faster start-up performance and runtime performance. But why mention this here? Our expectation is that site owners should see much higher cache hit rates with Firefox 4 as we dynamically set the cache size based on how much space is free on an end-user’s hard drive.

WebGL

Firefox 4 now has WebGL enabled by default. Based on the original 3-D Canvas work by Vladimir Vukićević, this is being widely implemented in browsers. The WebGL spec is on the short path to a 1.0 release and we’re very excited to see this be used in the wild.

Want a demo? Try the amazing Flight of the Navigator where we combine WebGL with a number of other technologies in Firefox 4 — HTML5 video, the Audio API, all remixed with live data from the web.

JavaScript

The new JaegerMonkey engine in Firefox 4 isn’t just faster, it’s also got some new tricks as well. Our goal is to bring new tools to developers and that includes evolving the JavaScript language. Here are two examples of where we’ve made other improvements:

ECMAScript 5

Firefox 4 Beta 9 contains much of the new version of the JavaScript language. Our goal with Firefox 4 is to have industry-leading support for ECMAScript 5, including the new strict mode. You can track our progress on the ES5 bug.

Web Console

Firefox 4 will include the Web Console. This is a new tool that will let you inspect a web page as it’s running, see network activity, see messages logged with console.log, see warnings for a page’s CSS, and a number of other things.

Note this that is something that we’ll be including with Firefox 4 directly. It’s not an add-on.

(Also Firebug will be ready for the final Firefox 4 release.)

HTML5

Firefox has always had excellent support for HTML5, even as far back as Firefox 3.5. Firefox 4 builds on that history with a bunch of new HTML5-related features.

Forms

We’ve started to implement much of HTML5 forms. We include support for new input types, datalist support, new input attributes like autofocus and placeholder, decoupled forms, form options, validation mechanisms, constraint validation and new CSS selectors to bind them all together. There’s a great post up on the Hacks site covering our HTML5 forms support in Firefox 4. If you want more information, check it out.

Parser

Firefox 4 includes an HTML5-ready parser. This parser brings with it some new capabilities, most notably inline SVG, but also improves performance by running the parsing algorithm on its own processor. It also brings our parser algorithm closer to the standard and lays the foundation for consistent parsing across browsers.

Support for WebM

Firefox 4 includes support for WebM, the new royalty-free format for video on the web. It works on YouTube if you join their HTML5 beta. It also works with embedded YouTube videos if you use their new iframe embedding API. (Join the beta and see an example at the bottom of this post.)

Video Buffer API

We now support the buffered attribute for HTML5 video. This means it’s possible to give users an accurate measure of how much video has been buffered instead of having to guess from the download rate and your current position in the stream.

Video “preload” support

We’ve replaced the “autobuffer” attribute for HTML5 video with the new “preload” attribute. This attribute gives you much better control over how videos are pre-buffered if they are included on a page rather than the old on/off system that was included with Firefox 3.5.

History pushState and replaceState

Firefox 4 now supports the HTML5 pushState and replaceState history modification calls. These allow you to create or modify the browser navigation history. These are extremely useful for applications that might want to generate history entries using the hash after the URL (useful for HTML-based slides, for example.) Other sites have been using these APIs to hide history information so that site-internal navigation aids aren’t revealed as part of HTTP-referrers.

Audio sampling and generation API

Firefox 4 includes the Firefox Audio Data API. This API allows you read, modify and write data from audio and video elements. This is now being widely experimented with and people are building some very beautiful things with it.

DOM

Firefox 4 includes a bunch of new DOM functionality, in addition to the performance improvements I mentioned before.

Added support for .click() to the File upload control

You can now call .click() on a hidden File control in order to bring up the platform file upload widget. This means you don’t have to expose the (ugly) file upload control; instead you can build your own. If you combine this with the new File APIs and progress events and you’ve got a recipe for a very nice file upload experience.

Support for .slice in the File API

We now support the Blob API and the .slice APIs that come with it. This is useful for people who want to want to process small parts of an otherwise large File object from JavaScript. You no longer have to load the entire file into memory.

It’s also useful for people who want to reliably upload large files. With some server and JS code you can now split a large file into small sections and upload those chunks, including re-retrying failed sections, or even uploading several sections in parallel.

Support for File API URLs

We now support the .url attribute for the File API. This lets you take objects that you’ve gotten through the File API and use them for images, video, HTML or other URL-powered objects.

Touch and multi-touch events

Firefox 4 supports both touch and multi-touch events, exposed to the DOM. Support for this functionality is available on Windows 7 systems.

Detect click-to-touch

You can now tell if a mouse or finger generated an event with the mozInputSource property. This is useful with the touch and multi-touch events and makes it possible to build apps that treat touch and mouse input differently.

IndexedDB

Firefox 4 will include a super-early version of IndexedDB. This emerging standard for local storage is still undergoing change and will be private-prefixed until it’s stable. We have some early API docs on IndexedDB, but the spec and implementation we have in Firefox 4 have both changed since the docs were last updated. As we get closer to release time we’ll be updating the docs and talk more about the implementation. Meanwhile, you can read the IndexedDB primer for an overview of using the IndexedDB API.

FormData

Firefox 4 includes support for the new FormData object, which makes it easier to interact with HTML forms. It also enables some new capabilities, like making it easy to upload a file as part of a form accessed via the File API.

SVG Animation and SMIL

In Firefox 4 you can now animate SVG with SMIL.

SVG as Images and CSS backgrounds

You can now use SVG as the source of an <img> tag. You can even animate them with SMIL. And you can also use SVGs as backgrounds in CSS.

Get a Canvas as a File object

Many people wanted a Canvas accessible as a file object for uploads and other purposes. You can now use the mozGetAsFile() method on a canvas and it will return an image file.

Resizable text areas

If you’ve been using a beta, you’ve noticed that text areas are now resizable by default. You can disable that with the new resize CSS property.

CSS

Firefox 4 includes a huge pile of new CSS properties and promotions from the private CSS namespace into the final namespace due to the maturation of some of the standards in this space.

CSS Transitions

Firefox 4 will include support for CSS Transitions. Since the spec is still early, these are still -moz prefixed extensions.

calc()

We now support an early version of calc private-namespaced as <a href="https://developer.mozilla.org/en/CSS/-moz-calc">-moz-calc</a>. This will let you use simple expressions anywhere you would normally want to use a length. This can make the CSS layout of pages much simpler. (No more divs for spacing!)

-moz-any()

We now support a new extremely useful CSS extension: -moz-any() selector grouping. This will be very useful in HTML5 contexts. Please read the post for more information.

-moz-element()

The <a href="http://hacks.mozilla.org/2010/08/mozelement/">-moz-element</a> is an extension to the background-image property that lets you use any element as the background for another element. This is hugely useful & powerful and we hope that other browsers will adopt it as well.

-moz-placeholder()

The <a href="https://developer.mozilla.org/en/CSS/%3A-moz-placeholder">:-moz-placeholder</a> allows you to change the attributes of background text that’s a placeholder in an HTML5 form. This allows you to change the color or other attribute of the text. This can be very useful if you’ve changed the style of the actual text box and you want the background text to match.

border-radius

The border-radius attribute is now supported, replacing the old -moz-border-radius attribute.

box-shadow

<a href="https://developer.mozilla.org/En/CSS/Box-shadow">box-shadow</a> has replaced -moz-box-shadow.

-moz-font-feature-settings

Firefox 4 will include support for exposing much more of the capabilities of TrueType fonts with the <a href="https://developer.mozilla.org/en/CSS/-moz-font-feature-settings">-moz-font-feature-settings</a> property. It’s possible to take advantage of all kinds of font capabilities — kerning, ligatures, alternates, real small caps, and stylistic sets, to name just a few.

Consistent CSS units

We’ve changed our handling of pixel sizes to match Internet Explorer, Safari and Chrome so that 1 inch always equals 96 pixels. See Robert’s post for more information on these changes.

Support for a physical CSS unit

We’ve introduced a new CSS unit, mozmm for the rare instance where you actually want a physical size to be used. Once again, see Robert’s post for more information on this new unit.

device-pixel-ratio

Firefox now supports the <a href="https://developer.mozilla.org/En/CSS/Media_queries#-moz-device-pixel-ratio">-moz-device-pixel-ratio</a> media query that gives you the number of device pixels per CSS pixel.

resize

As mentioned above, we now have a <a href="https://developer.mozilla.org/en/CSS/resize">resize</a> CSS property that lets you disable resizable input text areas.

-moz-tab-size

We now support the -moz-tab-size property that lets you specify the width in space characters of how to render a tab character (U+0009) when rendering text.

-moz-focusring

The new CSS pseudo-selector, -moz-focusring lets you specify the appearance of an element when it’s focused and it would have a focus ring drawn around it. Different operating systems have different conventions for when to draw a focus ring or not and this lets you control the look of form controls while keeping to platform conventions.

-moz-image-rect

The new -moz-image-rect lets you use a sub-rectangle of an image as part of a background or background-image.

Security

Last but not least, Firefox 4 supports a huge number of new security tools, useful for both users and web developers alike. Here’s a quick overview of the new technologies we’re delivering:

Content Security Policy

Content Security Policy (CSP) is a set of tools that web developers can use to help prevent a couple different classes of attacks. In particular, it offers tools to mitigate cross-site scripting attacks, click-jacking and packet sniffing attacks.

Another important piece of CSP is that when one of the rules is violated, Firefox can send back information about that violation to the web site, making it a useful canary to improve security for other browsers too.

X-Frame-Options

Firefox 4 now supports the X-Frame-Options header, one defense against clickjacking. This response header is supported by other browsers as well. (This was also delivered as part of a Firefox 3.6 update, but is worth calling out since it’s new since the original 3.6 release.)

HSTS (ForceTLS)

Firefox 4 supports the obtusely-named HTTP Strict Transport Security (HSTS) headers. You can use these headers to tell the browser that it should never, ever contact a site over unencrypted HTTP.

Firefox users can also use the STS UI add-on to add and remove sites from the HSTS list, even sites that don’t natively support HSTS.

CORS Improvements

We’ve fixed some bugs in our CORS implementation.

:visited changes

Firefox 4 includes the changes required to help improve your privacy online by closing a decade-old hole in CSS rules that let any website query your browsing history. These changes have also been picked up by WebKit-based browsers and we’ve heard rumors that IE 9 might pick up this important change as well.

That’s a lot of stuff

Yes, it really is! We hope that you like it.

109 comments

Alfred Kayser

And you forget to mention all the UI changes, which also brings a lot of awesomeness:
1. The new addons manager.
2. better integration with OS platform: MacOS, Windows Glass/Area, etc…
3. Tabview/panorama
4. Appmenu
5. Integrated web development tools
6. Sync
7. Many other little changes, making Firefox much friendlier and speedier to use.

January 14th, 2011 at 12:25
Ryan Grove

“Firefox 4 now supports the HTML5 pushState and replaceState history modification calls. These allow you to create or modify the browser navigation history. These are extremely useful for applications that might want to generate history entries using the hash after the URL”

Seems like this paragraph is confusing pushState/replaceState with onhashchange. They’re two different things that can be used for similar purposes, and onhashchange isn’t new in FF4.

January 14th, 2011 at 13:20
Shmerl

> And, of course, OSX users have excellent OpenGL support,
> so we’ve got that covered as well.

Hmm, what about Linux?

January 14th, 2011 at 13:24
1. Boris
  
  We tried enabling OpenGL on Linux, and discovered that most Linux drivers are so disastrously buggy (think “crash the X server at the drop of a hat, and paint incorrectly the rest of the time” buggy) that we had to disable it for now. Heck, we’re even disabling WebGL for most Linux drivers, last I checked…
  
  If your drivers are decent (some of the closed-source ones can be, nouveau can be sometimes), you do get something akin to Direct2D on Linux through XRender, though. So while you don’t get compositing acceleration, you do get faster canvas drawing and the like. drawImage, for example, can be much faster on Linux than on Mac. But only if you manage to find a driver and X version that happens to not suck…
  
  We do plan to put more work into the Linux end of this, look for workarounds for the various bugs, etc. But we could really use some help from Xorg and distros and the like here…
  
  January 14th, 2011 at 13:39
  1. Arpad Borsos
    
    Even for decent closed source drivers like nvidia that neither crashes nor incorrectly paints, enabling layers acceleration makes firefox a lot slower than with software compositing.
    
    January 15th, 2011 at 02:18
  2. David
    
    Thank you for that insight!
    
    I was wondering where Intel’s native drivers on many netbooks fall. Considering their open nature, I would hope that they’d fall under the ‘decent’ category, but I wouldn’t make assumptions. So, do you know if they are decent (for Firefox’s purposes), or do they crash the X server at the drop of a hat?
    
    January 15th, 2011 at 02:49
    1. Boris
      
      David, I don’t know what the Intel driver situation is, offhand. My general impression from the bugs I saw is that they’re no better than everything else, but don’t take that as gospel.
      
      January 15th, 2011 at 08:44
  3. Martin
    
    On Linux, I do not have problems with Nvidia-GPUs using their proprietary driver. If I test the hardware rendering results of the firefox 4 beta whith grafx bot, I get only one rendering error.
    
    Can you be more specific which GPUs and which drivers are buggy or if you are going to disable the complete hardware acceleration on Linux.
    
    January 15th, 2011 at 04:03
    1. Boris
      
      The nvidia proprietary driver is actually the one stable one we’ve dealt with, yes. I think the current plan is to enable WebGL for that one, but as I understsand GL-accelerated rendering on Linux was deprioritized once it was clear how much work it would be to get it to work in general. So I think that’s off by default on Linux, though you can turn it on if you want via preferences.
      
      January 15th, 2011 at 16:35
  4. pd
    
    Or Linus’ debatable bull-headed decision not to freeze driver APIs could be reversed and stop causing the adoption of Linux to be held back for years as it has been already.
    
    January 15th, 2011 at 04:13
    1. oiaohm
      
      Really It would help of modern day drivers were DRI2. That has only been around for 4 years so far.
      
      Really the argument over driver API is a false one. Nvidia and ATI both have wrappers around there closed source drivers so rendering that issue null and void.
      
      Now quality of these drivers is another matter completely.
      
      Since the closed source drivers are based on DRI1 designs they have the huge mother flaw of DRI1. Limit of 1 opengl application at a time stable. This was fine when DRI1 was dreamed up.
      
      So stable driver api is the problem here. The video card drivers are keep on using a stable api that should have been killed off 4 years ago.
      
      What is the big thing video card makers don’t like about DRI2 is the introduction of the requirement for open source memory management of video card by the kernel.
      
      This is due to a lot of errors with DRI1 writing into memory where they should not have been. And this was part DRI1 design issues again.
      
      Funny enough the open source ATI and Nvidia drivers are DRI2 but are lacking performance at this stage. Don’t have as many stability issues.
      
      January 15th, 2011 at 04:30
    2. Momiji
      
      This should explain why Linux doesn’t have a “stable driver API”:
      http://www.kroah.com/log/linux/stable_api_nonsense.html
      
      January 15th, 2011 at 09:12
  5. Bert
    
    Is it possible to re-enable OpenGL on Linux, either at runtime or compiletime? Also are there any good test cases to trigger the bugs mentioned above?
    Would be good to be able to stress test and debug the X11 drivers, i remember a similar issue occurring when compiz was new but most drivers now seem to work quite well with it.
    
    January 15th, 2011 at 05:23
    1. Boris
      
      Yeah, it’s just a preference. You can flip it if you want to experiment. Set “layers.acceleration.force-enabled” to true and “layers.acceleration.disabled” to false. You can use about:support to see whether you’re getting GL-accelerated rendering after that.
      
      January 15th, 2011 at 16:28
      1. Ernst Sjöstrand
        
        Hmm don’t you need export MOZ_GLX_IGNORE_BLACKLIST=1 also?
        
        January 18th, 2011 at 12:30
dude

Looks cool. Would have been nice if benchmarks were included.

January 14th, 2011 at 14:00
Taimar

Any news on CSS3 gradients?

Webkit has: http://webkit.org/blog/1424/css3-gradients/

January 14th, 2011 at 14:12
1. Norman
  
  If you had read the article, you would know the answer.. “WebKit and Mozilla have now implemented this proposal […]”
  
  January 14th, 2011 at 17:47
2. Anthony Ricaud
  
  You’ll find documentation and tutorials on https://developer.mozilla.org/en/Using_gradients
  
  This is already in Firefox 3.6.
  
  January 15th, 2011 at 06:52
jkulak

So many things I’ve been waiting for. Great. mozInputSource! I’m checking that out right away.

January 14th, 2011 at 14:22
Rodolfo

cool !!
what about websocket… ? i read something like security issues ..some time ago !!

January 14th, 2011 at 14:51
1. Janet Swisher
  
  WebSocket is disabled in Firefox 4 pending resolution of a protocol-level security issue. That hasn’t changed.
  
  January 14th, 2011 at 15:47
thinsoldier

When are the browser devs going to get together with the developers and start standardizing major features across browsers so that we can USE THEM NOW!?

With a collection of specs this huge and each browser maker randomly implementing bits and pieces of them as they feel like it, it will take ages for us to get to a point where you can easily develop in a true cross-browser fashion without having to keep abreast of the latest -moz / -webkit / -o prefixed features and the differences between them (css gradients for example).

There should be quarterly milestones where the browsers makers ask the developers “What 5 features would you like to see 100% available in all browsers 3 months from now?” And then they all make it happen.

Here’s my top 5

1. Pixel Perfect rendering consistency for border-radius, box-shadow, and text-shadow.
( I think IE9 has the best border-radius at the moment )

2. -moz-imagerect
Since the first time I heard “css-sprite” this is what I was thinking about! This is the best thing EVER. Straighten out the bugs/inconsistencies, put it in the official CSS spec and make everybody implement it NOW!

3. Pick webkit or mozilla’s css gradient syntax and make it official already. At this point I don’t care anymore. I just want one to be official so everybody can implement it and we can USE IT without worry.
Has there been any progress in this area? It seems the world has given up and we’ll be declaring all our gradients TWICE until the end of time.

4. Get a Canvas as a File object

5. Form Data and Added support for .click() to the File upload control

Wouldn’t it be nice if everyone can say on June 1st 2011 (2nd quarter of the year) that their browser is compliant with
“W3C.2011.2” (or whatever you want to call it) and that all browsers have at least TEN NEW, highly desired features that work PERFECTLY!

January 14th, 2011 at 15:59
1. Boris
  
  The problem is that standardizing on something that’s broken cause lots of pain later. We’re _still_ suffering pain from some early CSS and HTML standardization decisions that just weren’t thought through….
  
  Past that, different browsers have different priorities in terms of what they think is important. This is sort of a good thing: competition in action and all.
  
  January 14th, 2011 at 18:03
  1. thinsoldier
    
    I understand that. What I’m asking for is for them to periodically come together and focus on a tiny handful of features to get right so we can use them soon. I’m asking for them to once in a while make the developers and true cross-browser reliability their top priority. Just a handful of features (about 5) every 3 months. It’s not a whole lot to ask.
    
    I just read that webkit decided to with mozilla’s approach to css gradients. Sure it’s still -moz/-webkit prefixed. But at least it’s a lot more consistent. Now we just needs Opera and IE to add gradients then they can find 4 more (relatively small) important things to agree on in the next 2 1/2 months. Like -moz-imagerect, css3-multicol, and the flexible box model. Why can’t it be the goal of everyone to get the flexible box model finalized and working in all browsers by Dec 2011 so we can finally use it in 2012. I don’t care what other features are someone’s top priority, if that feature is not being worked on by ALL BROWSERS then it isn’t that useful in reality.
    
    January 15th, 2011 at 07:57
another_sam

Hi Boris,

Do you know whether the upcoming Wayland is going to improve the situation with WebGL and Linux?

Although it is the platform I use daily, I think it is ethically unfair and technically undesirable to have to work extra for Linux just because their drivers are buggy.

January 14th, 2011 at 15:59
1. Boris
  
  I don’t know what the Wayland situation looks like, sadly, or whether anyone even knows that.
  
  Sadly enough, GL drivers on Windows aren’t that great either. This is why WebGL is done via Direct3D on Windows now…. but that mostly a matter of performance issues.
  
  January 14th, 2011 at 18:07
  1. oiaohm
    
    Beware here. Linux closed source opengl drivers share common code with there windows relations. Large sections of the Nvidia binary blob is pure cut and paste from there windows driver.
    
    So yes all those windows opengl errors normally end up on Linux as well.
    
    Linux is not allown with the opengl issue.
    
    January 15th, 2011 at 04:33
    1. Boris
      
      Note that we’re not using the GL parts of those drivers on Windows. But yes, back when we were it was pretty buggy.
      
      January 15th, 2011 at 16:31
    2. Shmerl
      
      Actually Nvidia produces best OpenGL drivers for Windows (as well as for Linux and other Unixes). ATI ones are way more inferior.
      
      January 17th, 2011 at 09:45
helena boyd

Happy to see all the improvements on the new version. My personal problem on Firefox has to do with Flash player when I use the online game site. When are you going to address this horrible piece of garbage from Adobe? I just tested running Firefox 4 beta 8 along with 7 other Apps(IE, Office, Adobe Reader, Powerpoint, Access, Excel, Front Page) running all at once. Was running smoothly between sites for a long time without problems. When I have just Firefox running with one window, one tab, cleaned out cache, etc., running the online game site with Flash Player, it looses connection to server or freezes or crashes computer within a few minutes. How can it be so devastating? I don’t get it!

January 14th, 2011 at 16:11
1. Irek
  
  Yes, i agree ! I use linux and the latest flash from adobe (32 bit or alpha 64 bit) – all done the same, freezess some time on on-line games. Loading rom internet stops an i must restart firefox and try to play again. Stability is horrible and i don’t know, from there are the alll problems with firefox and flashplayer plugin on Linux.
  
  January 15th, 2011 at 16:25
tagada456

Firefox 4 beta 9 : super fast, quick lauching and very interesting with a lot of innovations. Some bugs will have to be corrected. Very good !

January 14th, 2011 at 16:46
Pam Griffith

How is :-moz-focusring different from :focus?

January 14th, 2011 at 17:43
1. Boris
  
  The summary in the article is actually plain wrong.
  
  :focus matches when an element is focused.
  
  :-moz-focusring matches an element when it’s focused _and_ would have a focus ring drawn around it.
  
  So the latter matches a subset of the elements the former matches. It turns out that depending on operating system, there are different conventions for when to draw a focus ring or not. As I recall, on Windows it’s something along the lines of: if the element was focused via a mouse click, and keyboard navigation was never used in that focus window, don’t draw a focus ring. Otherwise, draw a focus ring.
  
  This is the behavior :-moz-focusring tries to expose to web pages; the idea is to let web pages stick to the platform convention while custom-styling their focus rings.
  
  January 15th, 2011 at 20:35
raven

This is the world’s first third-generation JavaScript engine, using Baseline JIT technology similar to engines found in other browsers and kicked up a level with the Tracing engine found in Firefox 3.6.

I’d like to find out more on the following questions:
1. Are there any further information on how JavaScript engines are classified into generations, and what is the differentiating point about being a third-generation JS engine?
2. Is JaegerMonkey a compile-only JS engine now, or does it still run code with an interpreter first, followed by a baseline JIT, and then the tracing?
3. And is the tracing engine based on the interpreter or the baseline JIT now?

Any hint would be grateful, thank you :-)

January 15th, 2011 at 01:29
1. Boris
  
  1) I’m just guessing here, but I think the obvious generations for JS engines would be interpreter-only, jit, and multi-level jit with dynamic recompilation using a compiler that does more optimizations for the hot paths.
  
  2) At the moment JagerMonkey only runs compiled code, but when we decide to trace a loop we drop back into the interpreter for one loop iteration, because the interpreter drives the trace recorder. That’s something we plan to probably change, but it was too much work to get it done in the Firefox 4 timeframe. There have also been some suggestions to run a function in the interpreter a few times before compiling it with JM, to save memory and in some cases time (because compilation costs time, and if a function runs only once it may not be worth compiling it).
  
  3) Not sure what you mean by “based” on, but the tracer records a trace by getting callbacks from the interpreter with the opcodes the interpreter is interpreting. For now.
  
  January 15th, 2011 at 20:31
  1. raven
    
    Cool, thank you for the reply :-)
    
    1) If the generations are defined in such a way, then Carakan in Opera probably would have made it into being a third generation, because it runs in mixed-mode. Same for IE9’s Chakra. More true for Chrome’s V8 Crankshaft, but of course it came out later than JaegerMonkey. Although, none those competitors do tracing yet.
    
    2) That’s exactly the answer I’m looking for. And it explains 3) as well.
    
    January 16th, 2011 at 00:50
    1. Boris
      
      Yeah, I’m not sure I buy the whole “generations” thing all that much. Carakan definitely does some sort of recompilation, I’m told; I haven’t looked much into what Chakra does yet.
      
      January 16th, 2011 at 09:08
    2. pd
      
      Opera, LOL. Why do people still take it seriously? Mobile? Meh. Nintendo? Meh. Some fanboys seem to live their lives wishing to point point out firsts that Opera achieves. What is the point? Nobody uses it!
      
      January 16th, 2011 at 10:38
Georg Portenkirchner

Sounds nice, but it crashes right when I start it.

Mac OS X 10.6.6

January 15th, 2011 at 02:49
David Bruant

Proxies (http://www.slideshare.net/BrendanEich/metaprog-5303821?from=ss_embed) are also in Firefox 4 (I haven’t been able to make them work yet, but that’s another problem)

January 15th, 2011 at 02:50
guybrush

The problem with that approach is that they’d have to learn something about software engineering. It’s just easier for them to do whatever they want without caring at all about whatever they’re breaking with every new release.

January 15th, 2011 at 04:43
fjpoblam

Great improvements, and I’ll use it more often once more add-ons come onboard…

Two things, though:

(1) In spite of your speed improvements (which are indeed are quite notable!) Firefox still hasn’t reached near competitiveness with Chrome, Webkit nightly, and Opera on my Macbook Pro (MacOSX 10.6.6)

(2) It would surely be handy to have something analagous to the “quick-dial” sort of page presented by Chrome, Webkit, and Opera.

January 15th, 2011 at 09:00
bobz

The blank tab instead of a recent visited previews like chrome is a deal breaker. Im tired of installing plugins to make FF work like chrome. That is the single best feature of chrome, panorama does not cut it folks.

January 15th, 2011 at 09:05
1. Isaac Aggrey
  
  I agree. Unfortunately, it seems like App Tabs took the focus in the Firefox 4 betas (since the home tab is an App Tab), and there’s no project lead for the Home Tab at the moment (https://wiki.mozilla.org/Firefox/Projects).
  
  I’m hoping we’ll see a unique mix of the ideas from the Mozilla labs home tab design challenge (http://design-challenge.mozillalabs.com/winter09/) issued about a year ago in nightly builds sooner rather than later.
  
  January 15th, 2011 at 11:05
fanen

Poor linux. It is also my preferred OS, and news like this always makes me weak. I hope that all the awesome guys who make it possible are listening and thinking of a way out of this quagmire.

FF4 has been awesome so far. Panorama is the best thing since sliced bread.

January 15th, 2011 at 09:21
wiltjk

While I totally like what’s under the hood and the look of Firefox 4 – I still give up on it after a few days because of the pervasive memory leaks it and it’s add-ins have. Leaving it open overnight consumes giga-bytes of RAM. I would hope a better memory management framework would be introduced sooner than later.

January 15th, 2011 at 09:54
1. Boris
  
  Any idea what sites you had open in that session?
  
  For what it’s worth, there are a few leak fixes for regressions from 3.6 that are still slated to land for Firefox 4. So I’d give final a spin once it comes out, too.
  
  January 16th, 2011 at 19:00
Bill Frank

Is one to conclude that Firefox 4.0 has not moved to a process per tab? If that’s true, why? Wouldn’t process per tab be a better base from which to improve security? Also, third party tools that monitor Windows processes could be used to identify which tab/website is exhibiting anomalous behavior. If all the tabs are running in a single process, standard Windows tools will be of no help.

January 15th, 2011 at 10:20
1. Boris
  
  Firefox 4 is not process-per-tab, correct. Mobile Firefox based on Gecko 2.0 is. The reason desktop Firefox is not is that converting the UI and extensions to work with process-per-tab is a good bit of work, and there just wasn’t time to do it for Firefox 4. It’s definitely being worked on; we just didn’t want to delay shipping Firefox 4 for at least several more months here.
  
  January 16th, 2011 at 18:18
Sleeping

I’d also add to this pile of awesome the 64bit native support :)
Maybe something almost nobody will notice, but it’s good news for sure, now that most of the Windows 7 sold are x64 :)

Good job, Mozilla :)

January 15th, 2011 at 10:39
Ken Saunders

So what’s the big deal?
All of that and Firefox still doesn’t have my coffee waiting for me when I wake up.

Seriously though. Kick a** job!

Why we choose to bitch about what doesn’t meet our own exact expectations and desires instead of focusing on what is absolutely awesome is beyond me.
I won’t be throwing the first stone because I’m just as guilty of doing it as others.
If it’s productively pointing out bugs and serious issues, that’s one thing.
If we’re talking about what we don’t personally like, well, that’s another and Firefox is open source so we can just go rebuild a browser ourselves or shut up.

“Im tired of installing plugins to make FF work like chrome”

Um, then just use Chrome.

January 15th, 2011 at 10:57
Kitsune

That link– the Flight of the Navigator– is painfully slow withh Firefox 4 beta 9 on my 4GB (3.2GB, since it is 32-bit) duel core GeForce computer… I suspect that this is due to the lack of hardware acceleration on Linux, which is really to bad… Linux is really getting the bad end of the deal with this Firefox version, we only get the bad interface changes (lack of status bar) and none of the good, aside from some really smooth tabs…

But, I’m still going to keep using Firefox, simply because nothing I’ve tried is better– other than chrome, which doesn’t have the add-ones and other things I’ve become accustomed to.

January 15th, 2011 at 11:14
1. Hans W.
  
  @Kitsune: No PAE?
  
  January 17th, 2011 at 04:47
Bret Treasure

“Could not initialise WebGL” Flight of the Navigator still on tarmac.

January 15th, 2011 at 12:51
LaC

Does Firefox 4 have Keychain support on Mac OS X, like Safari and Chrome?

January 15th, 2011 at 14:37
William Dorsey

I checked it out because of a problem I see right below this comment box: Capcha type images simply do not show up. I tried the sound challenge and I guess we’ll see if I heard well enough.

I first tried 4B9 with EMAIL THIS, got no image, then tried to report by clicking the sad face and got no result. Could not even report its operation.

I quit, trashed 4.0 B9 and opened 3.6.13 to see where I might find a place to report. So I took this one. Machine: Mac Pro 10.6.6, 2 x 2.8 GHz Quad-Core, 10GB. Comcast Broadband, SurfBoard Wireless modem (but computer is Ethernetted to it).

January 15th, 2011 at 16:05
jose

great work!! Loving this massive features set, will try it immediately!

January 15th, 2011 at 16:48
kn33ch41

I’m pleased to read that the -moz prefix has been dropped from the box-shadow and border-radius properties.

I’m really excited to see how quickly Firefox4 gets adopted.

January 15th, 2011 at 19:34
Jeff W

This is nice and all, but the basics are still broken. Printing is still some of the worst in Firefox compared to other browse. When will the basics be fixed?

January 15th, 2011 at 19:43
abu abdulla

thanks for this great browser

January 15th, 2011 at 20:48
Pam Griffith

So if I’m already using :focus to style focus rings, does this mean I also have to use the new one or risk having 2 focus rings in ff, my own styled one plus the default (the way buttons work now, actually)?

January 15th, 2011 at 21:20
1. Boris
  
  It depends on the styles involved. Anything that matches :-moz-focusring matches :focus as well, so as long as you’re overriding the default focus style you’ll be ok… except you will be making things have a focus ring when platform convention is that they shouldn’t.
  
  January 16th, 2011 at 18:08
componentes informaticos

The new beta is really very very fast

January 15th, 2011 at 21:25
Marush Denchev

Hello,

I’m sorry to say that but WebGL on Firefox 4 beta 9 isn’t working! I tried several demos from learningwebgl.com and even the Fight of the Navigators demo – same deal. It always says to me that “Couldn’t initialize shaders”. Please, make sure its working correctly before launching.

I made the SunSpider test. My Firefox 4 beta 9 scored 740ms, and my Chrome 8 – ~400ms. I think something is wrong ….

Thank you.

January 16th, 2011 at 02:57
Stuart

Sounds good, might give ff another chance, have been using only chrome for about a year now, mostly for performance.

January 16th, 2011 at 04:03
pd

You forgot to include these fun features:

– Destroying RSS feed autodiscovery (you’re average user is not going to know to put the button back from the customize menu)
– Obfuscating the status bar and replacing it’s critical-for-security URL preview function with a very messy greyed right-align location bar text and thus polluting the simplicity of the location bar
– Butchering the familiar menu for a big orange, ugly, slower menu button inspired by just one of your three main supported platforms

January 16th, 2011 at 04:46
1. Henri Sivonen
  
  “- Butchering the familiar menu for a big orange, ugly, slower menu button inspired by just one of your three main supported platforms”
  
  The old menubar can still be enabled even though it isn’t enabled by default. (Right-click a piece of blank space on one of the toolbars.)
  
  January 16th, 2011 at 06:04
rahim

I was and I am still a big fan of Firefox, but Firefox 4 looks like a new browser.

Why did your move the status bar into URL bar?

Firebug is great tool for developers. Why do you kill the ecosystem of Firefix and integrate your own development tools? The average user doesn’t need any development tools.

January 16th, 2011 at 08:41
1. Boris
  
  rahim, Firebug is going to work with Firefox 4. Don’t worry about that.
  
  January 17th, 2011 at 08:15
names

just installed new beta on os x 10.6.6 – lost ability to use track pad gestures (ie pinch to zoom) – huge loss for me. :'(

also, memory usage is still absurd unfortunately. really want to use firefox, but it’s using over 1.5GB of memory with 5 tabs open some times. right now I have only this tab open, just fired up the app and 304MB. safari with same page open, 49MB. ouch.

January 16th, 2011 at 17:01
1. Anthony Ricaud
  
  For the trackpad gestures, http://antennasoft.net/robcee/pinchy/ can restore those.
  
  January 17th, 2011 at 06:01
2. Boris
  
  names, the trackpad behavior can be changed via preferences or the extension Anthony linked to.
  
  For the memory issue, is this the “Real Mem” column from Activity Monitor? Or “Private Mem”? Or one of the others? Which page do you have open when you see the 304MB usage?
  
  January 17th, 2011 at 08:14
Hans W.

[blockquote]a maximum of 60fps, the edge of human perception.[/blockquote]That’s not completely correct, but it doesn’t matter.

January 17th, 2011 at 04:53
1. thinsoldier
  
  Somewhere on geeks3d,com there’s an app that shows a 3d scene split in 2 with adjustable framerate on either side.
  
  I can defintely see a big difference between 60 and 75 frames per second.
  
  In quake 3 / quake live I can also a difference between 60 and ~100 fps.
  
  January 18th, 2011 at 09:44
  1. another_sam
    
    what’s your screen refresh rate? mine is 60 Hz.
    
    in my case, computing more than 60 fps is useless.
    
    January 18th, 2011 at 10:08
Phil

The vast majority of Firefox users are on Windows. Personally, I think Mozilla should just turn on the OpenGL code for Linux & tell the desktop people to (wo)man up & fix the code.

Those that don’t want Firefox 4 can just stick to Firefox 3.6 in the interim.

(BTW, you can show the bugs in the freedesktop bugzilla that you’ve filed for all these Xserver cxrash bugs, yes?)

January 17th, 2011 at 05:55
1. Boris
  
  Phil, I don’t know whether bugs have been filed; I haven’t been working directly on that code.
  
  What I _do_ know is that the crash data is from crash reports, not from actual testcases we have. So we have aggregate data showing that users with particular graphics hardware and graphics driver crash a lot and we have some data about what the registers and such looked like at time of crash, but we don’t typically have symbols on the user’s machine for their X server, so can’t point to the code that’s crashing, and we don’t typically have a way to reproduce the crash… All of which unfortunately limits the ability to file a useful bug report.
  
  January 17th, 2011 at 09:39
  1. Phil
    
    I see. That does pose difficulties! Can you tie firefox into the Gnome (Does KDE have something similar? I think it does) crash reporter infrastructure if it’s there? That gives full backtraces & will use the local symbol information to construct them: users can install the debug packages if they have a repeatable crash.
    
    January 17th, 2011 at 10:00
    1. Boris
      
      I think if the debug packages are there we do pick them up and use them (though I’m not 100% sure of that). But they’re usually not there…
      
      We definitely need to spend some time having nightly/beta users run with GL acceleration and debuginfo and generating useful stacks, etc. But there just isn’t enough time in the Gecko 2.0 timeframe for that. :(
      
      Of course users who want to help can always flip the pref and see whether they crash.
      
      January 17th, 2011 at 10:14
      1. Phil
        
        Might help to add a request to install the debug packages for their distribution to the bug report dialog then? Is the crash reporter capable of scanning the stack a second time? If there are missing symbols it could ask the end-user if they want to install debug packages for the library in question & then resolve those symbols before submitting the crash report.
        
        January 19th, 2011 at 02:56
      2. jospoortvliet
        
        KDE’s bugreport tool can automatically install the needed debug packages. Maybe you can have a look there and see if you could add it to Firefox’ debug tool… ???
        
        March 24th, 2011 at 10:40
Philippe V.

I think firefox 4 should have an option to retain its old UI, at least until people gain confidence to try and get used to the new UI.

January 17th, 2011 at 09:02
michael

why cant iget my back forward arrows on firefox ive stopped using firefox whivh like because of this

January 18th, 2011 at 06:00
llewton

Well for me the new FF is a huge pile of shit, then, and pardon my French, since I use Linux. I understand it’s an objective difficulty, not something to blame only FF for. But you’re offering a sub-standard version to Linux users and I’ll have to graciously decline. After four years I’m changing browsers, although frankly I don’t want to. For all it’s shortcomings I liked using FF.

January 18th, 2011 at 09:15
1. pd
  
  Did you read the article? I think the pile of shit here is clearly Linux or more specifically it’s craptacular history of pathetic video driver issues.
  
  January 18th, 2011 at 23:52
  1. Phil
    
    Maybe so, but it’s a *little* hard for the driver writers to fix crash bugs if they don’t get reported to them!
    
    January 19th, 2011 at 02:51
Aric

Well, I for one love the changes, and yes the speed in Beta 9 is very noticeable, especially on two of my older machines. (Intel desktop and AMD laptop). There are three issues I have, however. One is keeping Chrome as my default choice, despite Google’s questionable information gather practices.

1. No inclusion of sand-boxing for separate tabs. This is the deal breaker. I understand that this would delay the release, but it would not have had it been a priority in the early planning of FF4. It’s been two years now since Chrome was introduced. All browsers should have followed suit for security reasons alone. It is so frustrating when one bad process in one single tab brings the whole browser down. Until Firefox has separate tab processes, it will not be my first choice.

2. On the issue of browser crashes: On my old Pentium 4 desktop, and my wife’s newer multi core, Firefox 4, especially Beta 9, is very stable. But on my old AMD machine the bowser crashes constantly. I have not been able to go longer than a hour at this point. I assume this has something to do with a bad or conflicting driver, but I have yet to isolate it.

3. Addons . . . seriously, there cannot be upgrades without breaking them damn near every time? Sorry to mention Chrome again, but Google updates it constantly, and their is never a broken addon (extension). They always work from version to version.

I want to like Firefox. I really do. But until there is the inclusion of sand-boxing, and some serious soul searching when it comes to addons, I have no choice but to stick with Chrome.

January 18th, 2011 at 15:24
1. Boris
  
  Aric, you seem to underestimate how much work actually creating a multi-process architecture is. It took Chrome 2 years (which happened to be the 2 years _before_ they first announced it existed) or so, and they were working from scratch, not trying to maintain compatibility with existing code as we are here. We’ve been working hard on it for a while now, and it has in fact been a priority through the whole Firefox 4 cycle. However it took most of that cycle to get the core parts of it working (which is why Fennec can ship with out-of-process tabs). There just wasn’t time for the equally large job of updating all the Firefox UI code to work with the new setup.
  
  As for addons… the only way to keep addons from breaking when you update is to restrict what they can do to a limited API and not change that API. That’s what Chrome has done, but the tradeoff is severely limited power of the addons. We have that, with Jetpack, and people are using it right now. But there are addons that can’t be done that way so far (if ever). And for addons that aren’t using a limited API, we have to assume they’ll break. As does the addon developer; after all, _they_ are the ones that set the maxVersion, not us!
  
  If you have addons that seem to you like they should be jetpacks, do poke the addon author to change to that! We’ve been doing some of that, but there’s obviously inertia of the “this code is working; why change it?” sort.
  
  January 19th, 2011 at 10:05
Matt

I’m running Fedora 10 x86_64 on my thinkpad X301. The OpenGL driver is unusable. Upon enabling compiz OpenGL desktop (w/ adjustably translucent windows, the gui feature of the future, mark my words), I have five minutes until the OpenGL driver locks up my computer *COLD*. Cold, as in, the only thing that can be done is hold the power button down to reboot. OpenGL drivers need to become a *much* higher priority for Linux.

January 19th, 2011 at 16:41
1. Phil
  
  Fedora 10 was released more than two years ago & went into feature freeze before the X301 was shipped if the relevant dates I tracked down on the web are correct.
  
  Try upgrading to the latest release?
  
  January 21st, 2011 at 04:34
  1. Phil
    
    Looking more closely: Fedora 10 shipped with the previous generation i810 intel graphics driver, whereas current Fedora ships with the Intel authored “intel” graphics driver. Intel has put a lot of work into the latter: I’d upgrade if I were you.
    
    January 21st, 2011 at 04:52
    1. Matt
      
      Phil, that’s great, thanks for the info. Now.. to suck it up and upgrade.
      
      January 29th, 2011 at 18:39
bahram

We definitely need to spend some time having nightly/beta users run with GL acceleration and debuginfo and generating useful stacks, etc. But there just isn’t enough time in the Gecko 2.0 timeframe for that.

Of course users who want to help can always flip the pref and see whether they crash.

January 20th, 2011 at 12:33
Daquan Wright

I’ve been using beta and it’s snappy! The speed boost is great, I love it. UI changes are nice and definitely take Firefox up a notch.

Only bad thing that happened is that Firefox crashed on me while I was loading up a few tabs, but it only happened once. Hopefully it won’t be a recurring thing.

January 20th, 2011 at 22:41
Manjurul

Can you please solve the problem in windows 7, the open tabs are not showing in the task bar when a mouse pointer is brought on the firefox icon there, which was in beta 8. It now only shows the current tab.

January 25th, 2011 at 05:51
Matt Richardson

Ok I’ve just updated to the latest nightly and yeah I have to admit it’s fast. I really like these changes and look forward to what firefox brings to the table in future releases.

January 25th, 2011 at 08:01
Maximilian

I love this!

January 26th, 2011 at 13:09
Mike

After using the Betas for sometime, switching to 3.6 is just… ugh.

So while there are obviously a lot of things that can be done to push FF further, I for one and really happy to see the UI changes, startup speed, JM… the Lot. Its great!

I run 4b10 portable so i don’t use the IE7 installed on this company’s computer, and should I remind you guys on this XP 32bit computer, Sunspider is done in something like 250ms… where IE7 is something like 22,000ms. The biggest jump is one test is done 2800 times faster.

We’re never going to get it perfect, but certainly we are starting to lay down some ground breaking stuff. No all the issues reported are FF, some are users ignorance, others the OS (and im not pointing my finger at the Linux users), and some are just probably poorly configured stuff. who knows, or cares. Fix it or use… whatever else. why come to mozilla and just complain.

I think we all need to be happy that we have this new browser coming out and its like what FF3 did to FF2… I remember the day FF3 came out and was just… completely wowed. Using the Beta, I feel the same way. And yea, I don’t use the panorama thing, i think it sucks too!… and blank tabs are dumb as well, but who cares… Someone’ll come up with something and if your that upset about it, well… instead of bitching, man up and do it, or find someone to do it for you. Go ahead… use IE.

January 29th, 2011 at 13:17
R

I hope 4 matches all the hype. I was an early user of Firefox and used to recommend it to all who would listen but gave up on it last year and switched to Chrome and the regular fallback, IE. Too many crashes and other problems with 3. I’ll wait until the final release of 4 to try it but I’ll be gone quickly after the first sign of trouble. Developers may be OK with a bad browser they can tinker with but I just want something that works. I run Win7 Pro.
I’m good with followup comments but no spam please. Thanks

February 9th, 2011 at 16:06
EUGENE TAGTMEYER

This really sounds great. I have been using FireFox 4 and it keeps crashing and will not clear the history. I uninstalled it and hope that when I download FireFox 4 9 it will be much better.

February 14th, 2011 at 21:38
Wissem

Firefox is all about the Open Web right ? You guys need to do more and more about Linux Desktop users.I bet that Linux users are the most bug reporters you had from the very begining of Firefox beta ;)

March 3rd, 2011 at 17:31
1. Paul Rouget
  
  > I bet that Linux users are the most bug reporters you had from the very begining of Firefox beta ;)
  
  No, you’re wrong here.
  
  But yes, we know that Linux users are important :)
  
  March 3rd, 2011 at 18:34
Siddharth

Firefox 4 is really cool. Ever since I started using Firefox (Fanboy since FF2.) It has crashed like 10 times? Less than 10 I guess. I love the skin of Chrome but I don’t want to leave Firefox. So I downloaded Firefox 4 and installed a Chrome skin. What was cool was, I was able to see the Panorama button on the far right. I wasn’t able to see it in the default theme. But now I could.

Firefox rocks! :)

http://hacktivist.tumblr.com/

I have all the tricks and tips of Firefox 4 listed here.

March 3rd, 2011 at 22:41
Lars

Letting any website modify (read and write?) my browser history sounds a like a really bad idea (-> privacy). Also, I often review my history to find an article I read the other day. What if the website doesnt want me to and deletes any specific links, so that I always have to start from the front page again (to see more adds along the way)?

If you let any website popup an Open / Save / Upload dialog without my explicit wish, please at least keep the “Really want to upload these files?” dialog ;-)

The other features sound great!

March 4th, 2011 at 04:26
pip010

jaaa PUT some attention to Linux users. Mozilla you are a shame to OSS!

April 18th, 2011 at 03:37
1. louisremi
  
  Many developers at Mozilla do use Linux as their main OS and report bugs/issues they encounter on their platform. Of course, more attention and time is spent on the most widely used platform: windows.
  
  April 18th, 2011 at 09:09
arbsb

I think firefox 4 should have an option to retain its old UI, at least until people gain confidence to try and get used to the new

December 12th, 2012 at 11:18

Comments are closed for this article.

Hacks

Firefox 4 Beta 9 – a huge pile of awesome

By

Performance

WebGL

JavaScript

Web Console

HTML5

DOM

CSS

Security

That’s a lot of stuff

109 comments

Firefox 4 Beta 9 – a huge pile of awesome

By

Performance

WebGL

JavaScript

Web Console

HTML5

DOM

CSS

Security

That’s a lot of stuff

Discover great resources for web development

Thanks! Please check your inbox to confirm your subscription.