Thursday, December 1, 2011

9.0b1 available

9b1 is available, corresponding roughly to Firefox 9 beta 4. This was a rather troublesome port -- Mozilla did some large internal changes in this release to facilitate type inference (which we do not yet support, stay tuned) and the architectural requirements needed caused significant delay in simply getting the browser to build. Even after that, in DEBUG mode it worked reasonably well but with VMX/AltiVec code paths enabled it crashed incessantly and I had to disable two of our text converters. I'm hoping we can get them reenabled for either 9 final or 10.

It also seems, based on comments in the previous blog entry, that there are still some sites with ridiculously large or complex numbers of scripts that still cause us to run out of stack. For 9, I've made a bandaid and backed the stack pointer all the way up to 0xf0000000 in memory, for a total of 1GB of stack. (On systems less than 1GB of RAM, it doesn't use this automatically, but it potentially could. In this case, it will get swapped to disk, so your system may thrash like crazy but it won't crash; the stack will then shrink back down after execution completes. For this reason, 1GB is now the recommended minimum, though we will still support 512MB machines.) Even with this "bandaid," this obviously doesn't mean we won't overrun it again in the future, and I'm unable to think of any way I can wring more stack out of the browser in 32-bit mode and 64-bit mode is not an option for any architecture except G5.

Methodjit will change this, but I have no idea if it will change it for the better or not. The key issue is that because of our very large register set and our requirement to abide by the OS X PowerPC ABI, we must save large stack frames to the stack, and our stack cannot dynamically grow unlimited. (This is a good thing -- such sites could destabilize the entire computer rather than just the browser if they were allowed to allocate stack forever.) Methodjit as currently written limits us to a much smaller register set, currently 16 GPRs and 8 FPRs of which all the FPRs and around half of the GPRs must be saved on the stack (plus the usual OS X ABI linkage area overhead). This is a smaller stack frame than tracejit uses, which can potentially use all nearly all the GPRs at once, but it may not save us because it may be easier for methodjit-generated functions to recurse with less checking (and that smaller set of registers in use may have performance impact, but I talked about this with Mozilla and it does not appear likely to change -- methodjit is limited to a total of 32 registers altogether). We are exploring ways to propagate an imminent stack exhaustion state to the browser so that a window like the "Unresponsive script" dialogue can be generated rather than, you know, crashing. If you have some ideas about that, see issue 114.

9 is the first installment of what will become methodjit, if we can get it done. This includes Ben's hard work on the macro assembler plus my additional hacking on YARR JIT to enable us to compile regular expressions, which was a gap we suffered from before. With regular expression compilation, the quad G5 running at full tilt drops its SunSpider numbers from around 1600ms to about 1050ms in 9. Yes, this is slightly slower than 8+YARR, probably due to some additional overhead in the interpreter, but it is still significantly faster than 8 alone. (As a side effect, methodjit compilation is enabled, but it does not work. If you were naughty and turned on any of the methodjit preferences in about:config, turn them off before upgrading to 9.0 or you will crash!) On sites like Twitter, it makes a big difference, and it will also accelerate certain extensions like Ghostery and AdBlock Plus. Think of it as a down payment on more JavaScript wizardry to come.

Even though we had to back out some of the AltiVec text conversion code, 9 also includes Tobias' AltiVec qcms colour management code and the completion of the AltiVec scale and colour conversion code, which improves WebM performance quite a bit. It also corrects a regression with JPEG decoding that Chris found and that Mozilla caused -- now JPEG AltiVec decoding is really really fast, and G3 is much faster than it was in 8.0.

9.0 makes a few small subtle interface changes to things like the go/reload/stop button, for really no good reason, but whatever. There are also additional HTML5 and CSS features, font stretching, and improved AJAX performance with a revamped, "chunked" XHR system.

So let's gaze into the crystal ball for a moment and consider some possibilities. Firefox 10 will be the last version of Firefox to have tracejit; it's gone in 11. Preferentially we will have our implementation of methodjit available for 10 beta and we must have it for 11, or we'll have to keep dragging a tracejit-able JavaScript to future versions, which seriously hurts our portability. We could really only fire a "gun" like that once, maybe twice, before changes in the JS API and other internal limitations make it impossible to merge an old JS into a later browser. The long and short is that we really need to have methodjit if we want to continue with source parity. If not, then we drop to feature parity and go from there.

This gets a little more interesting (and exhausting) in that Mozilla is now talking about dropping support for 10.5 in Firefox 13, which was inevitable. It's probably worth reviewing when Mozilla dropped 10.3 for Fx3 and then, of course, when they infamously dropped 10.4 for Fx4 which is why we exist in the first place. Like I say, it was inevitable for Leopard support to have its number come up so quickly; there are few reasons for Intel users to stay on it (Snow Leopard is faster and leaner and still runs PPC software), and Tiger was a much longer lived version of Mac OS X than Leopard was. It is also worth noting who drives each proposal to end support (hint: same person each time). Just sayin'.

The reason this interests us is that while there were many things in 10.5 that we could emulate in 10.4, there are many things in 10.6 (and, for that matter, 10.7) that we can't. Things like, for example, Grand Central Dispatch, or other hidden UI interfaces, or the graphics stack. Right now we simulate the dependency on CoreUI by using the old chrome code, CoreText with Harfbuzz and NSTrackingArea with cleverer management of events (and there are some 3rd party versions of it we could use if we had to), and 10.5 is limited to software rendering also, which makes things easier for us because we are also limited to software rendering and Mozilla has to support that. But it will be much harder when 10.5 compatibility goes away, because Mozilla will make assumptions about the capabilities of the class of remaining machines which many Power Macs will not meet, and will almost certainly try to leverage some of the new features available now that they don't need to worry about legacy support.

But wait, the plot thickens with a partridge and chickens. Most of us have already said our piece on rapid release (and there is some evidence that it is hurting Mozilla's market share already) and more reasonable elements within the Foundation have determined that having a long-term support branch might be worth it (the so-called Extended Support Release, or ESR). The ESR would be the second-tier release and users would be discouraged from running it, but it would be available for corporate or managed environments where rapid-release makes regular Firefox burdensome to manage. 3.6 is sort of filling that role now, so this would finally end updates to 3.6 and replace it with another long-lived branch, and then periodically update it according to a regular, slower timeframe. This idea is not new; the original ESR plan called to start around Fx8, and now it's talking 10, and in all likelihood I don't see much traction on it until the Fx12 or 13 timeframe.

Wait, did you say Fx13? The ESR is an important release for us: it guarantees the ground doesn't shift under our feet more than necessary and we get a certain degree of security patches. While Mozilla will discourage the ESR for regular users, there is nothing that says we can't build on it, and the ESR will be supported for at least 6 months, probably longer. So here's how the scenarios will play out. If we can hang on and make the jump until Fx13 (assuming that is the ESR basis), then we will be on a stable platform with security updates that we can continue to build on. If we develop past the ESR, and we are unable to maintain it, we could be marooned on a Firefox branch that has no updates (and has the requisite bugs from that release to boot). Nothing says that past the 10.5 cutoff date that we will still be able to keep the browser afloat.

So the current plan is to do whatever it takes to get us to the ESR and then start making official releases based on that, while continuing to generate beta releases in parallel off mozilla-beta as we have been doing. If it looks like we'll make it to the ESR after that, then we keep going. If not, we fall back on the ESR, no harm done, and backport features to that as feature parity. When the ESR ends, we enter security parity. That's still a lot of life left, and did you notice that TenFourFox has already had its one year anniversary? Break out the champagne and cheese, man!

As usual the beta will break the QuickTime Enabler because the Add-On SDK team doesn't have the foresight to get a working SDK to coincide with it in the Add-On Builder. Because of the tardiness of this release, the QTE will simply be a maintenance update, and I will post it when it is available.

46 comments:

I apologize in advance for still commenting here and not in the bug tracker, but I am 1) too lazy to sign up for a google account and 2) not sure that my comment is helpful.

Well. 3.6 apparently doesn't crash. We know that 3.6 is interpreter-only, so if we only could find a way to return to the interpreter... but TM does it all the time, whenever one of its assumptions fails! At least that's what tracemonkey paper says. (If you're interested why I read it: it loads in the pdf.js demo viewer). And do it after just, say, 256MB of stack use, to avoid thrashing.

Also need to stop entering jitcode (in this compartment at least) until stack use goes down.

Am I the only one whose bookmark menus look like this in TFF 9 (G3 & G4 versions, 10.4 & 10.5): http://postimage.org/image/violr552n/ ?

Placeholders and folder icons are there, but most or all site icons missing. Happens also with fresh profile and small bookmarks collection. Icons in the bookmarks toolbar work. Places Maintenance Extension doesn't fix this. Reverting to TFF 8 with the same profile shows that all icons are actually there, only TFF 9 doesn't show them. Probably a Mozilla bug, but found no related bug report, so this may only affect us.

Just tried the 7400 build on an old 466 D.A. G4 and it is GREAT so far!! *****HAVE AN UNRELATED QUESTION THOUGH****** Is it possible to ad a feature that lets the user save their TenFourFox data to a custom folder, and thus allow the use of multiple builds of the program? I generally like the latest build for speed and features, but find that the older builds (especially 7) were better for add-on support like Firebug, which I use as a web-designer a lot.

Can anybody reproduce this?: with "One Finger Snap" installed, place the pointer in a open space in the navigation tool bar & hold down the click button until the View->Toolbars contextual menu pops up. A brief wait then a spinning ball, contextual menu flashing like crazy in the bottom right of the display & the eventual crash. It doesn't happen in FF 3.6 & who would even use OFS on a MacBook but it goes back pretty far in TFF(4.03).

Everything related to the behavior of the contextual menu is a long and sad story in Mozilla products. You might want to toggle „Disable or replace context menus“ in Prefs/Content/JS…/Advanced and see if it has any effect.

I've never heard of One Finger Snap. If it's a Firefox addon, then I agree it's a bug and it should be fixed. If it's a system haxie or some other sort of OS modification (this? http://www.old-jewel.com/onefingersnap/index.html ), I'm very doubtful unless someone can reproduce something similar without it. It may not even be our bug.

I'd want it to be demonstrated it can be triggered reliably without it; that means it's clearly our bug. The fact it worked with 3.6 doesn't necessarily mean that it's not doing something untoward, it just means it didn't break 3.6. The fact that the crash spills into the Dock and Finder really makes me think 1FS is doing something it shouldn't be with the operating system.

Trouble is that while I was curious enough to install the Outwit Images extension to a TFF test profile to see what's wrong, I'm not going to install a haxie like Onefingersnap OS X systemwide, without knowing if I can get rid of it cleanly again.

Thanks for your job with TFF! One problem: html5 video is just unwatchable on g4 1.67GhzHere is a nice app for viewing youtube http://mrgeckosmedia.com/applications/info/YouView and it works better than mactubes IMHO, so maybe you can place this link somewhere in your TFF site

2ClassicHasClass With mactubes i can play only 360p video with acceptable speed (via quicktime of course), higher resolution videos are noticeably slower. And youview allows to play 480p video smoothly (besides this app uses one interface window for playing and searching with nice toggle between those modes). Anyway I keep both apps.

Has hacked the flash plugin to make websites like Facebook and CNN and Hulu think they are seeing 11.1. I've tried it out (in Omniweb, trying to keep tenfourfox flash free) and can confirm they all work now, no annoying error messages. Really makes you wonder what if any "new features" Adobe has added to flash since they decided to stop supporting PPC.

Oh, this article names the fellow who "drives each proposal to end support" -- thus brilliantly cutting down Mozilla's userbase and alienating many formerly loyal users, a business plan that may have helped Chrome take the #2 spot among browsers....

Well I think we knew that name before (look up the surname in a German-English dictionary). Nevermind. I'm perfectly fine with TFF.

Regarding the hacked Flash: If one *wanted* to trick a website into believing Flash 11 was installed on a PPC Mac with Tenfourfox, one would actually just need to edit pluginreg.dat (in the FF user profile) accordingly (11.1.102.55 & 11.1 r102) and keep on using whatever plugin is installed. One would thereby utilize a stupidity in Firefox, viz. that this browser reports to the website whats in that file, not what's actually installed. Even if one exchanged the plugin with the hacked one (and one wouldn't do this on a production machine, for heaven's sake), TFF would still report the old version "10.1" as long as pluginreg.dat isn't updated. In any case, one would *not* have to install a plugin from an unknown (in this case certainly well-meaning) source and make one's Mac even more vulnerable than it actually is from the original Adobe plugin (on second thought, can it get any worse?). Safari users would need to install the hacked version, though.

cnn.com was spitting out "you need to update your flash player" error messages until I applied the hack. If it doesn't play well (barely plays on my ibook 1.2ghz) you can right click and set quality to low.

I didn't know I could do that in TFF, but I am used to not having it now and actually far prefer the QTE, Mactubes, Niceplayer hacks.

The hacked Flash is about half the file size of the original (10.1), and upon trial (in Safari), works faster on my 400 MHz PPC G4 (at low resolution), so that I don't see the annoying "stutter" that had been a perpetual nuisance on YouTube. I had avoided watching video online, preferring to download, watch from disk, and then delete, as the only way to avoid stutter. This hacked Flash has fixed the problem.

The hacked flash isn't any different. It couldn't be. The size is smaller because he removed language files. The only other difference is that he changed the plist files to get it to report the wrong version. There are still more files he could have removed. Right now it's a plugin within a plugin for some reason.

Unlikely now, as FF still has a lot of market share. Imagine that half of the users switch to Bing as a result of Google dropping the deal and Mozilla changing the default search engine. The other half will be pissed off and drop FF, but it would still be a net loss for Google.

Even if the Mozilla Corporation ended up taking it on the chin and took the Mozilla Foundation with it, the people who work for Mozilla would probably still be contributing to it. Firefox would simply go back to being a primarily community-maintained project, with sponsorship from those commercial entities that need it.

But, as zubr says, this is unlikely. Google would suffer a massive PR black eye for killing off a competitor in such a fashion, and the FTC already has an eye firmly fixed on them for their anti-trust investigations. They would not be so stupid as to give Bing a big leg up or be seen as the company that torpedoed Firefox.

Exactly. Also 9 is still in beta. If they haven't fixed it by the release, there will be lots of reports since it seems to be a general bug, even with a fresh user profile, not just a "special setup" bug. So this is just a matter of time.

Hello! Thank you for your great browsers. :) I have two offers: can you add to QTE 480p? Because 360p is too low quality and 720p too choppy.

And Youtube is a little big buggy: when I watch a movie with flash player ( sorry but I need it and FP is very important for me! HTML5 is toooo slooow) and I choose the middle of window size it does nothing and is buggy!

@f4c5ef80-24d7-11e1-b39d-000bcdcb2996 Hello! You should try Mactubes or Youview. I predict you will love either, as long as your Power Mac G4 is 700mhz or faster and has at least 32mb of VRAM. Also, you could try Coreplayer, if you have 20 bucks you can part with. With Coreplayer 720p streaming is possible on my ibook G4 1.2ghz. Start a HD download in mactubes, drag it onto Coreplayer and sit back and enjoy.

We have a bandaid in hand for the bookmarks problem; see Mozilla bug 705516. I might work on a definitive fix later, though we never had decode-on-draw before and we certainly won't miss it if we have to have it disabled for awhile.

I saw all the problems Mozilla has been having with their Windows 32-bit linker barfing on libxul. (For those who don't understand why this is amusing to us, we had to use Tobias' linker to get around a similar problem "way back" in Fx5.) Payback's a b*tch, isn't it? :D

Methodjit is down to six tests that still don't pass -- that's out of over 1700. Almost there!