People like 5's speed; 6 is not IMHO appreciably faster, but does not appear appreciably slower either. It is a bit more busy, however. Recent patches to garbage and cycle collection have calmed this down, supporting my theory that more aggressive garbage collection is the reason, and on my G5 5.0 used around 3% CPU at baseline whereas 6.0b1 now uses around 6-7%. This is less on my iBook, which went from 2% to about 4%, but still higher. Fortunately this does not seem to translate to poor responsiveness, and the browser in my informal measurements does seem to be hanging on to less memory, so at least it's achieving its purpose. The big changes for memory usage, however, will not emerge until Firefox 7.
As mentioned, 6 adds mostly under-the-hood features again, chief amongst them Mozilla's personal flavour of WebSockets; more HTML5 features; media query support; and some handy but unspectacular developer tools. There is also about:permissions, which doesn't really do much for me compared to the (much faster) Preferences tab and isn't exposed in the UI which implies it's not doing much for Mozilla either. Still, these are necessary changes, and at least they're out in our hands faster, so rapid release is at least achieving that goal even if it's cheesing off the rest of the known galaxy over the version number creep in the process.
In the bug fix department, 6.0b1 fixes the issue with 10.5 and Java that Apple deliberately caused (see bug 668639), as well as Twitter's site redesign that causes the browser to stall out on fat regexes (issue 77) and cut down on spamming the console log with debug information (issue 70).
Also, I managed to get ahead of schedule with my move and sit down with some custom code. Specific to 6.0 are two AltiVec-enhanced changes for text and HTML processing: a VMX text fragment scanner, which improves dynamic operations on pages by 10-15%, and AltiVec-accelerating UTF-8 to Unicode conversion. Because OS X usually hands us 16-byte aligned memory allocations, even though we have no equivalent for the SSE2 unaligned store code in that routine we're still usually able to use the AltiVec fast path.
In addition, a double-pumped 128-bit algorithm is now available for AltiVec WebM YCbCr conversion, improving over 5.0's algorithm by 30-40% and translating to a real 5-10% improvement in video playback. Speaking of, Mozilla is futzing around with the buffering algorithm again. In 5.0, Mozilla would hold video in favour of audio, even if that meant stuttering the video. In 6.0, Mozilla will "pump video," even if the audio can't keep up, more along the way that 4.0 used to do it. I prefer the former, but I know some people prefer the latter. There is no easy way to switch between them and I bet 7.0 will change this around some more, but have your say in the comments.
Speaking of video, this is what you will now see by default if you go to a Flash-enabled player or application:
That brings us to plugins. Plugins are disabled, as warned. By default, this is what happens now:
- Sites will think you have no plugins installed. This is the correct behaviour, because that allows the site to present you with alternate (hopefully HTML5) content.
- If the site is hard-coded to use an applet, object or embedded plugin instance, the message above (or one like it) will appear. If the element is positively identified as a plugin, the "More information ..." link will take them to this wiki page on the subject.
- Both about:addons and about:plugins will show no plugins installed; about:addons will explain why.
Regardless, I did promise you that you can still opt back in. Before you do, understand the following caveats:
- The browser will always ship with them disabled. Your previous setting will stick, of course, should you choose to opt-in, but by default they will not function.
- No bug in plugin support, even a serious or crippling one, will ever hold a release back. While I may try to fix bugs if I have some spare cycles (as if!), I make no guarantees or promises.
- Application issues with plugins in operation, even crashes, may be WontFixed as bugs if other issues have precedence or for any other reason. However, bug reports with patches are welcome -- strongly encouraged, even. If you want something fixed and you can fix it, contribute. I've got enough work to do just fixing all the stuff Mozilla breaks in 10.4.
- Finally, plugin code may stop working at any time without warning. I'll reasonably endeavour to prevent this, but if plugin code is preventing the browser from functioning I reserve the right to stub it out entirely to get the rest of the browser to operate, and even if it does compile it may be utterly bogus.
- The master switch is tenfourfox.plugins.enabled, which by default ships set to false. In this mode, the browser pretends as if there are no plugins at all and all of the other settings are irrelevant. You can dynamically switch it to true and reload the page to instantiate the plugin, but it's best to restart the browser afterwards after flipping the switch to true to make sure that all of your plugins are re-enumerated properly.
- Embedded plugins are controlled by tenfourfox.layout.hideplugins. This ships also set to false, so embedded plugins are not hidden by default, assuming plugins are enabled. If set to true, this only prevents the plugin from starting up and operating; a placeholder will still appear on the page (usually blank space), and the page will still think that the plugin is operational in most cases. This setting is the riskiest one to enable, as it can facilitate drive-by instantiation of plugins.
- Scrolling plugins is controlled by tenfourfox.layout.smooth_scroll_plugins. This ships set to true, so that any instantiated plugin in that window will force smooth scrolling on to reduce graphical artifacts. This can be annoying on slower systems, so for them you may wish to set this to false.
- Full-page plugins, such as QuickTime objects and PDF files, are controlled by tenfourfox.layout.hide_fullpage_plugins. This ships set to false, so full-page plugins are not disabled by default, although due to painting bugs you may need to interact with them blindly to get them to start. If set to true, the plugin will simply not start when instantiated in full-page context, although it may still work embedded (such as QuickTime).
- The Java plugin is controlled specifically by tenfourfox.layout.hide_java_plugin, which ships set to true and applets requiring the plugin will not start (though other applets may). However, depending on your system, the Mozilla Java Embedding Plugin may not be what you want anyway; you may want the Apple provided Java Plugin. Remember that Java is deprecated and will become unsupported by TenFourFox when 10.5 is unsupported by Apple (which will be very soon now). Check that your applet works without plugin support before messing with this option, as certain Java applets will crash the browser within the plugin context.
Release notes and builds: