- There will be no beta 13. Even if Mozilla themselves do one, which seems unlikely but one never knows, we will not. There isn't enough there to justify it unless someone can demonstrate a serious blocking bug in beta 12.
- We will not bother with the Release Candidates. These are, at longest lived, highly ephemeral releases and every release we put out is another 70-80MB out of our Google Code hosting space. Releases this temporary are not a good use of our currently limited community resources.
- Once blokking boogs go to zarro, we will watch to see what Mozilla does next: if they immediately branch into a new mozilla-2.0 repo, then we will build off the repo after the branching. If they do not branch then (though they will branch eventually), we will continue the "advance" pulls we are doing now to avoid getting post-tag commit noise until they do.
- Once Firefox 4/10.4Fx goes into its own separate repo apart from mozilla-central, pulls and builds will only occur after everything has landed (as these maintenance repos are historically much more stable than the trunk, as you'd expect), which means our releases will be either on time or slightly after the fact. After all, Mozilla never tells me anything. We'll do our best to be timely, however.
Thursday, February 24, 2011
Beta, shmeta, real men release
So here's what's going to happen next.
Wednesday, February 23, 2011
Beta 12 released!
Before you all write and tell me, yes, I know the build says b13pre. That's because there was a last-minute security bug that landed and by the time I jumped on it, the build milestone had already been advanced. There's no real purpose in a checkin-and-out to simply massage the version number in a beta, so I left it as was. However, despite the version number, this is beta 12.
Okay, enough of that. Beta 12 has several new features and these are mostly good, some strongly so. First of all, the most visible change is that the hovered URL in the location bar is gone, as threatened, replaced by a Chrome-like strip at the bottom (the same one used to report network activity). I kind of miss the location bar layout, but I adapted back to the old style very quickly. The bar will move to the other side if you hover over it, so it doesn't get in the way. Second, there are small subtle changes (again) in tabs, including the close button, which is now just a tiny grey X in the default theme. The bogus new change is that the content-specific modal dialogue boxes are now super blah (I liked the quasi-Aqua ones in beta 11 better -- these are boring).
In the systems department, JavaScript is also improved -- my iBook/1.33 clocked a 400ms improvement on SunSpider, and Tab Candy is a bit sprightlier -- but the big one is memory pressure. Mozilla has been tracking some leaks in Firefox 4, some minor, some major, all bad, and a big improvement landed in the form of bug 630932. This bug dramatically increases the aggressiveness of the garbage collector and cycle collector, and for those of you like me with memory monitors in the menu bar, you can see the GC/CC quickly grabbing RAM back as you close windows and tabs. TenFourFox has more memory pressure than Firefox did, not just because of Gecko 2, but because we generate and cache machine code for the nanojit. Anything that helps to actively reduce footprint is welcome and this makes a big difference. For those paranoid about memory, here are some other memory leaks Mozilla is tracking, and some of these have fixes planned for final release.
Mozilla also made some significant changes to the plugin architecture on Mac, as I warned you about. I was able to hack around them (I think), but the time is coming when I might not able to. Flash performance seems slightly worse because of the changes (which favour CoreAnimation and hardware acceleration), but it's hard to get accurate metrics. I still advise downloading such videos to disk with any of the available video site/YouTube extensions and playing them outside of the browser.
Specific to TenFourFox, we have a few fixes landed in this release for a new problem and for a couple old ones. One of our oldest and most frustrating bugs was the awesome bar refusing to suggest anymore when you typed a totally novel URL it could not suggest for: when the box closed, it would not open again (though it could still receive keyboard events). I'm inclined to chalk this up to 10.4 being a brat who can't stand not knowing the answer, because I could not find a specific cause, and tweaks to the underlying object had side effects for other auto-complete objects. So, if you can't fix the cause, remove the situation. Starting now, if you type a new URL that the awesome bar doesn't know, rather than simply closing, it just shows a single blank box (actually a single blank stub suggestion). This works with the interface, and the awesome bar works normally. If someone else has a better idea, say so, or send me source code. :P
Also, for those of you who noticed some Command-key shortcuts weren't working, that should now be fixed, and a crash in the JavaScript nanojit was also wallpapered over. So what are you waiting for? Go get it!
I'll post later this week or early next what will happen for the final formal release. Until then, enjoy beta 12.
Okay, enough of that. Beta 12 has several new features and these are mostly good, some strongly so. First of all, the most visible change is that the hovered URL in the location bar is gone, as threatened, replaced by a Chrome-like strip at the bottom (the same one used to report network activity). I kind of miss the location bar layout, but I adapted back to the old style very quickly. The bar will move to the other side if you hover over it, so it doesn't get in the way. Second, there are small subtle changes (again) in tabs, including the close button, which is now just a tiny grey X in the default theme. The bogus new change is that the content-specific modal dialogue boxes are now super blah (I liked the quasi-Aqua ones in beta 11 better -- these are boring).
In the systems department, JavaScript is also improved -- my iBook/1.33 clocked a 400ms improvement on SunSpider, and Tab Candy is a bit sprightlier -- but the big one is memory pressure. Mozilla has been tracking some leaks in Firefox 4, some minor, some major, all bad, and a big improvement landed in the form of bug 630932. This bug dramatically increases the aggressiveness of the garbage collector and cycle collector, and for those of you like me with memory monitors in the menu bar, you can see the GC/CC quickly grabbing RAM back as you close windows and tabs. TenFourFox has more memory pressure than Firefox did, not just because of Gecko 2, but because we generate and cache machine code for the nanojit. Anything that helps to actively reduce footprint is welcome and this makes a big difference. For those paranoid about memory, here are some other memory leaks Mozilla is tracking, and some of these have fixes planned for final release.
Mozilla also made some significant changes to the plugin architecture on Mac, as I warned you about. I was able to hack around them (I think), but the time is coming when I might not able to. Flash performance seems slightly worse because of the changes (which favour CoreAnimation and hardware acceleration), but it's hard to get accurate metrics. I still advise downloading such videos to disk with any of the available video site/YouTube extensions and playing them outside of the browser.
Specific to TenFourFox, we have a few fixes landed in this release for a new problem and for a couple old ones. One of our oldest and most frustrating bugs was the awesome bar refusing to suggest anymore when you typed a totally novel URL it could not suggest for: when the box closed, it would not open again (though it could still receive keyboard events). I'm inclined to chalk this up to 10.4 being a brat who can't stand not knowing the answer, because I could not find a specific cause, and tweaks to the underlying object had side effects for other auto-complete objects. So, if you can't fix the cause, remove the situation. Starting now, if you type a new URL that the awesome bar doesn't know, rather than simply closing, it just shows a single blank box (actually a single blank stub suggestion). This works with the interface, and the awesome bar works normally. If someone else has a better idea, say so, or send me source code. :P
Also, for those of you who noticed some Command-key shortcuts weren't working, that should now be fixed, and a crash in the JavaScript nanojit was also wallpapered over. So what are you waiting for? Go get it!
I'll post later this week or early next what will happen for the final formal release. Until then, enjoy beta 12.
Friday, February 11, 2011
Coke is it. I mean, beta 12
Beta 12 is going to be the last Firefox 4 beta, so it will be the last TenFourFox beta too. There will be a couple extra 10.4Fx specific fixes, hopefully.
It's unclear when Fx4/Gecko 2 will get its own hg branch. Once it does, this will start the countdown to see if we jump to Firefox 5 with them on mozilla-central. Remember, it's not guaranteed that we will retain compatibility, and there is always the risk they could require a 10.5-only feature at any time, though a serious widget library incompatibility isn't likely to happen until they require 10.6.
Once Fx4 moves to a stable branch, changesets will be issued against that stable branch, and the unstable branch will be idle for an indeterminate period until Firefox 5 goes through a sufficient number of betas. More about that when it actually happens, and knowing Mozilla, I don't see this happening much before summertime.
By the way, Flash 10.2 came out, and as threatened it is Intel-only. It is unclear if there will be any more 10.1 fixes, and to even get 10.1 you have to find their archived Flash Player versions page. I'd advise you don't hold your breath over continued support. Flash Player 9 has been completely deprecated, so if you must use Flash, use Flash 10.1.
It's unclear when Fx4/Gecko 2 will get its own hg branch. Once it does, this will start the countdown to see if we jump to Firefox 5 with them on mozilla-central. Remember, it's not guaranteed that we will retain compatibility, and there is always the risk they could require a 10.5-only feature at any time, though a serious widget library incompatibility isn't likely to happen until they require 10.6.
Once Fx4 moves to a stable branch, changesets will be issued against that stable branch, and the unstable branch will be idle for an indeterminate period until Firefox 5 goes through a sufficient number of betas. More about that when it actually happens, and knowing Mozilla, I don't see this happening much before summertime.
By the way, Flash 10.2 came out, and as threatened it is Intel-only. It is unclear if there will be any more 10.1 fixes, and to even get 10.1 you have to find their archived Flash Player versions page. I'd advise you don't hold your breath over continued support. Flash Player 9 has been completely deprecated, so if you must use Flash, use Flash 10.1.
Wednesday, February 2, 2011
Beta 11 released!
Go get it!
As promised, the key grab is JavaScript acceleration now enabled for all platforms. If you get weirdness, check it by turning javascript.options.tracejit.content to false (and preferably restarting your browser). If that fixes it, report the site. Note that because the nanojit stores traces in memory for future cache hits, memory usage in this beta will be higher -- expect it. If this is a serious issue for your memory impaired system, turn that pref off as well. I also threw in a little helper for Gopher addicts like me, did some work on the title bar, and tried to work on the widget code a bit to help windows sort better.
Mozilla has, IMHO unadvisedly, decided to do some late-breaking significant interface changes. These changes are only partially in beta 11; the most noticeable is the status notation at the lower left during network exchanges a la Chrome. This is fine, no worries, and even welcome. However, Mozilla is planning to redo the location bar and remove the hovered URL, restoring it to its former location or something approximating that, and all that just as I'd gotten used to it in its current place. I suspect this will confuse users all over again who, like me, had become accustomed to the current layout; adding insult to injury, for whatever reason this does not seem to have made the cutoff for b11, and that's not a good thing either because the inevitable screaming about this needs to be dealt with early and not reserved for beta 12 (or 13). Nevertheless, expect some alteration in the next beta.
Mozilla is getting better about their time-based delivery and their estimates are becoming more accurate as the formal release nears shipping (I estimate mid-March). The big question is if there will be a beta 13. If there will not be, then we will release beta 12 and go formal. If there will be a beta 13, we will skip 12, release 13, and go formal. Heaven help us if there's a 14.
For builders, changesets will be up later tonight or tomorrow morning.
As promised, the key grab is JavaScript acceleration now enabled for all platforms. If you get weirdness, check it by turning javascript.options.tracejit.content to false (and preferably restarting your browser). If that fixes it, report the site. Note that because the nanojit stores traces in memory for future cache hits, memory usage in this beta will be higher -- expect it. If this is a serious issue for your memory impaired system, turn that pref off as well. I also threw in a little helper for Gopher addicts like me, did some work on the title bar, and tried to work on the widget code a bit to help windows sort better.
Mozilla has, IMHO unadvisedly, decided to do some late-breaking significant interface changes. These changes are only partially in beta 11; the most noticeable is the status notation at the lower left during network exchanges a la Chrome. This is fine, no worries, and even welcome. However, Mozilla is planning to redo the location bar and remove the hovered URL, restoring it to its former location or something approximating that, and all that just as I'd gotten used to it in its current place. I suspect this will confuse users all over again who, like me, had become accustomed to the current layout; adding insult to injury, for whatever reason this does not seem to have made the cutoff for b11, and that's not a good thing either because the inevitable screaming about this needs to be dealt with early and not reserved for beta 12 (or 13). Nevertheless, expect some alteration in the next beta.
Mozilla is getting better about their time-based delivery and their estimates are becoming more accurate as the formal release nears shipping (I estimate mid-March). The big question is if there will be a beta 13. If there will not be, then we will release beta 12 and go formal. If there will be a beta 13, we will skip 12, release 13, and go formal. Heaven help us if there's a 14.
For builders, changesets will be up later tonight or tomorrow morning.
Tuesday, February 1, 2011
Beta 11 builds in progress
Beta 11 is now in the pipeline, now that Mozilla has signed off on the green rev, and I'm running my quad's fans at full blast churning out builds tonight and tomorrow for release later this week.
I'll speak more about the release in a bit, but the big ones are additional performance improvements (both in display speed and baseline JavaScript), and also that the nanojit will be enabled for all CPUs, including G5. The G5 nanojit does not gain performance wins as massive as the G3 and G4, and it's still net slower in SunSpider. However, it is net faster in Dromaeo and V8, and the browser just feels faster with it. This was done initially by blacklisting JSOPs that empirically seemed to hurt, while keeping as many of the winner JSOPs as possible, and the result is best expressed in terms of Meat Loaf ("two out of three ain't bad"). I think I can do better here by getting even more low-level, but this is a solid start and gets all of the supported processor families at feature parity.
Because this version has G5-specific code paths, people working on their own builds should note the change in the recommended configuration file. In particular, you may need to add --enable-tenfourfox-g5 to it and/or define TENFOURFOX_G5 in files you want the alternate code path to be used. While this is only in the tracejit currently, and only then for G5/970, I may further expand this for more processor-specific code-level optimizations in the future. I'm also looking at adding processor macros independent of TenFourFox's specific settings, which will most likely be done at the compiler level (for example, the G5 version now also sets -D_PPC970_ for gcc). This will help others who want to use this code for non-Mac PowerPC systems.
More on the specific build in a couple days once the binaries are certified, but as a heads-up, it appears there will be a Firefox 4 beta 12. I am undecided if we will push out a b12 also or hang tight for the formal release, but there are still a lot of hardblockers and as usual I suspect there might well be a beta 13. How unfortunate, because as you can see,
... Firefox just wants to be released! Sorry, that was too cute not to share. :)
(image courtesy @philikon)
I'll speak more about the release in a bit, but the big ones are additional performance improvements (both in display speed and baseline JavaScript), and also that the nanojit will be enabled for all CPUs, including G5. The G5 nanojit does not gain performance wins as massive as the G3 and G4, and it's still net slower in SunSpider. However, it is net faster in Dromaeo and V8, and the browser just feels faster with it. This was done initially by blacklisting JSOPs that empirically seemed to hurt, while keeping as many of the winner JSOPs as possible, and the result is best expressed in terms of Meat Loaf ("two out of three ain't bad"). I think I can do better here by getting even more low-level, but this is a solid start and gets all of the supported processor families at feature parity.
Because this version has G5-specific code paths, people working on their own builds should note the change in the recommended configuration file. In particular, you may need to add --enable-tenfourfox-g5 to it and/or define TENFOURFOX_G5 in files you want the alternate code path to be used. While this is only in the tracejit currently, and only then for G5/970, I may further expand this for more processor-specific code-level optimizations in the future. I'm also looking at adding processor macros independent of TenFourFox's specific settings, which will most likely be done at the compiler level (for example, the G5 version now also sets -D_PPC970_ for gcc). This will help others who want to use this code for non-Mac PowerPC systems.
More on the specific build in a couple days once the binaries are certified, but as a heads-up, it appears there will be a Firefox 4 beta 12. I am undecided if we will push out a b12 also or hang tight for the formal release, but there are still a lot of hardblockers and as usual I suspect there might well be a beta 13. How unfortunate, because as you can see,
... Firefox just wants to be released! Sorry, that was too cute not to share. :)
(image courtesy @philikon)