Thursday, July 14, 2011

6.0b1 available

6.0b1 is now available, based on Firefox 6.0 "beta 2" internally (Mozilla, realizing the liability that rapid release is becoming, is trying to play down these numbers but ultimately I think that horse has already left the barn).

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.

There are some slight improvements to JavaScript performance due to code reorganization, but most of this is barely above the statistical noise threshold and probably isn't noticeable in practice.

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.

Without rehashing earlier arguments on the subject, plugins aren't being maintained for PowerPC, aren't secure, already can't access some content requiring later versions (such as Flash 10.2 and 10.3), already have bugs, and are being changed in Mozilla in ways that will likely make them incompatible anyway. I assume that if you read this blog, you are already aware of all this. It is not my intention to specifically break plugins, but I want it clear that I won't support them further and people use them at their own risk. Furthermore, the browser must ship in a safe configuration out of the box rather than expecting people to install things like Flashblock (which I heartily recommend). That said, plugin code is an integral part of the codebase, so there will always be plugin code in TenFourFox. There's just no guarantee that it will work, and 6.0 already has at least one change that will break compatibility with certain older plugins.

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 relevant plugin settings are in, natch, about:config. There are five specific settings related to plugins:

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.

For the record, I am putting my money where my mouth is. I'm watching my videos in MacTubes or over WebM, I view my PDFs outside of the browser, and listen to music files in QT Player and watch Flash videos with Perian. Security must come first, even at the cost of functionality or convenience. I hope you will agree, and even if you don't, I hope that you'll appreciate I've tried to meet you halfway with this back-door option.

6 comments:

On the websites I visit, it feels fast. The UI feels snappier as well. Menus with lots of favicons (Bookmarks, History) load faster. I didn't notice any slowdown compared to TFF5.0. Processor load when idle is about 2-3 percent (4 percent with the Facebook news feed page loaded all the way to the bottom).

Haven't decided yet how much I like the new html5 video playback settings. Video doesn't stall anymore, instead it slows down a little, and audio has to slow down too, resulting in that creepy gurgling sound which my ears don't tolerate. To be honest: I'm pragmatic. I join the Youtube html5 trial, watch some videos, then I leave it. Flash plays the same videos with so much less effort. With html5, I can watch videos, but I can't do anything else with the Mac simultaneously while the video plays in the background or in a side-by-side window.

using on emac g4 1.42ghz with 1 gig of ram. runs quite well i must say. html5 video plays much better now, not quite as good as safari yet which seems to dominate when it comes to playing html5 video but tenforfox is getting much better in this area i must say. keep up the good work, you guys have made my day with this release. thank you so much for the hard and tireless work.

Bizarre, that doesn't look like JavaScript at all (unless it's a bad symbol in the xpt that it's throwing a bad reference to). I'm not sure what to say about that one. When I get debug builds working again I'll investigate further.