- 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)
Friday, January 21, 2011
Their betas go to 11
Mozilla wants to freeze beta 10 this Friday and push it out next week, then freeze beta 11 the Friday of next week, and push beta 11 out the week after that (see this announcement). Besides my moment to say I told you so, two back-to-back betas in as many weeks is not good use of our more limited resources. If Mozilla pushes out beta 10 on schedule, which may in fact happen based on some of the rumblings I hear around Mountain View, then we will sit out beta 10 and go to beta 11. If beta 10 is delayed longer than next week, we will continue with beta 10. Watch this space or mozilla.dev.planning.
Wednesday, January 19, 2011
Plugins unplugged
For those of you who use Classilla on OS 9, you already know that Classilla allows you to turn plugins off, and in fact encourages it. It makes the browser more secure by not exposing old unmaintained native code, and it makes the browser more stable by not exposing old unmaintained broken code. If you really really really want to use Flash Player 7 to view something, or QT 6.0.3, you can, but you can turn it right back off again. When I am in OS 9, I just keep plugins off entirely. Plugin support for OS 9 has obviously not been updated in years.
The time is now coming for this state on PowerPC. Adobe has been making noises about ending PPC support for the Flash Player plugin for some time now, and their preliminary system requirements page for Flash Player 10.2, which is now in release candidate stage, finally makes this plain: PowerPC is no longer a supported platform for Flash, although they still support Tiger on Intel. When you download Flash 10.2, it's x86 or bust, similar to their dropping PowerPC from AIR support with 2.0.
Most of us know that Flash was never well-optimized for PowerPC anyway. Even on a fast G5 it chugs, and you can forget about full-screen or HD playback on G4s, let alone G3 systems. Losing Flash is not going to be a massive issue for functionality for awhile because much of the advanced functionality 10.2 introduces will not be widely adopted until 10.2 is. However, it is going to be an issue for security. Flash is a large potential and practical security hole, and while many of the exploits fortunately rely on x86 native code, some do not. Moreover, Flash-based privacy intrusions, while not bugs or security holes per se, have for a long time approached infamy in quantity and ubiquity. While my insiders tell me that Flash 10.2 is light-years ahead of 10.1 in performance, that certainly does not help us on our minority soon-to-be-unsupported architecture.
While Flashblock (at least until beta 9 ... fix it!) helped to block most Flash applets, and tools like AdBlock and NoScript can also serve in this capacity, the time is coming where TenFourFox will go the way of Classilla and block Flash and other plugins at the layout level. This has obvious benefits for security and performance, at the cost of losing Flash. Steve Jobs, bless him, was right to say that HTML5 supersedes many of the features Flash has long been (ab)used for -- not all, but many -- and I think that if we deal with this pain now, we will be better able to adapt. More to the point, Mozilla is moving towards plugin and graphics NPAPI models that no longer use QuickDraw (deprecated since 10.4, and almost certainly further marginalized in 10.7), and this will be an issue for 10.4 which lacks CoreAnimation. In the future it may not be technically possible to still use Mozilla's code base and maintain compatibility with the aging plugin base on PowerPC and Tiger, let alone the attendant disadvantages of continuing to use those plugins.
This post is more of a warning rather than an announcement. While I plan to ship TenFourFox 4.0 with plugin support, albeit deprecated, likely by 10.4Fx "4.1" plugins will be pref-ed off requiring you to manually re-enable them through about:config. At some point in the future when it is no longer technically feasible to support them, that code will be completely removed. Hopefully by then the impact of iOS will have introduced a world where Flash-free alternatives that are natively supported by TenFourFox and Gecko 2.0 are easily accessible.
The time is now coming for this state on PowerPC. Adobe has been making noises about ending PPC support for the Flash Player plugin for some time now, and their preliminary system requirements page for Flash Player 10.2, which is now in release candidate stage, finally makes this plain: PowerPC is no longer a supported platform for Flash, although they still support Tiger on Intel. When you download Flash 10.2, it's x86 or bust, similar to their dropping PowerPC from AIR support with 2.0.
Most of us know that Flash was never well-optimized for PowerPC anyway. Even on a fast G5 it chugs, and you can forget about full-screen or HD playback on G4s, let alone G3 systems. Losing Flash is not going to be a massive issue for functionality for awhile because much of the advanced functionality 10.2 introduces will not be widely adopted until 10.2 is. However, it is going to be an issue for security. Flash is a large potential and practical security hole, and while many of the exploits fortunately rely on x86 native code, some do not. Moreover, Flash-based privacy intrusions, while not bugs or security holes per se, have for a long time approached infamy in quantity and ubiquity. While my insiders tell me that Flash 10.2 is light-years ahead of 10.1 in performance, that certainly does not help us on our minority soon-to-be-unsupported architecture.
While Flashblock (at least until beta 9 ... fix it!) helped to block most Flash applets, and tools like AdBlock and NoScript can also serve in this capacity, the time is coming where TenFourFox will go the way of Classilla and block Flash and other plugins at the layout level. This has obvious benefits for security and performance, at the cost of losing Flash. Steve Jobs, bless him, was right to say that HTML5 supersedes many of the features Flash has long been (ab)used for -- not all, but many -- and I think that if we deal with this pain now, we will be better able to adapt. More to the point, Mozilla is moving towards plugin and graphics NPAPI models that no longer use QuickDraw (deprecated since 10.4, and almost certainly further marginalized in 10.7), and this will be an issue for 10.4 which lacks CoreAnimation. In the future it may not be technically possible to still use Mozilla's code base and maintain compatibility with the aging plugin base on PowerPC and Tiger, let alone the attendant disadvantages of continuing to use those plugins.
This post is more of a warning rather than an announcement. While I plan to ship TenFourFox 4.0 with plugin support, albeit deprecated, likely by 10.4Fx "4.1" plugins will be pref-ed off requiring you to manually re-enable them through about:config. At some point in the future when it is no longer technically feasible to support them, that code will be completely removed. Hopefully by then the impact of iOS will have introduced a world where Flash-free alternatives that are natively supported by TenFourFox and Gecko 2.0 are easily accessible.
Subscribe to:
Posts (Atom)