Looks like we might see additional radical UI changes in future versions of Firefox.
It seems a new Home Tab is also on the works:
Last edited by lovinglinux; August 1st, 2011 at 09:36 PM.
They have cut the chrome down so much already that any further changes can only be quite small really.
If they wanted to do Radical they should have added an option to stack tabs on the left...
... but this probably does not fit in with the current emphasise on mobile computing.
Last edited by SilverWave; August 2nd, 2011 at 02:44 AM. Reason: Added Details
More interesting proposed changes in Firefox 9.
Mozilla is discussing the possibility of making add-ons compatible by default and disabling those that are incompatible.
Stage 1: Definition
1. Feature overview
Firefox's switch to rapid releases has been stressful for add-on developers. Add-ons not hosted on AMO are especially pained, as they must update compatibility every 6 weeks without the benefit of automatic compatibility bumping.
Since the release of Firefox 4 and 5, we've learned that there are many more non-hosted add-ons than we previously thought, mostly those installed by other software. Whether users make use of these add-ons or not, seeing an incompatible add-on prevents many users from upgrading to new versions of Firefox.
More than 90% of add-ons are compatible from one version of Firefox to the next, and the ones that aren't usually have binary components that will need to be recompiled every release. If we change the default compatibility assumption, we can reduce the action needed to only the very small number of add-ons broken by the new release, rather than 100% of add-on developers.
We would move to a model where Firefox assumes add-ons are compatible unless they have binary components, the author has explicitly said to strictly observe stated compatibility, or it is reported to AMO as incompatible through the Add-on Compatibility Reporter.
It's possible and likely we will occasionally enable add-ons that don't actually work, but as we omit add-ons with binary components, this should not cause crashes and users will simply not have the functionality they expect, and will complain to the add-on author.
This process would not remove the need for AMO's automatic compatibility bumping, as it's still preferred for authors to be aware of changes in Firefox and learn about upcoming deprecations and other changes.Stage 2: Design
5. Functional specification
When Firefox needs to determine an add-on's compatibility, it should do the following:
1. If the add-on is marked as compatible with the version, nothing needs to be done. The add-on remains enabled.
2. If the add-on is not marked as compatible, Firefox will look at its install.rdf to see if the author has requested strict compatibility qualification. If they have, the add-on is incompatible and disabled.
3. Next, Firefox will look for binary components in the add-on. If binary components are found, the add-on is incompatible and should be treated as such (disabled).
4. If the add-on is not marked as compatible and does not contain binary components, Firefox should look at the metadata it received from AMO about the add-on. If the add-on is not reported as incompatible from AMO, it should be enabled as compatible.
For AMO, this will involve returning information on compatibility reports received in response to metadata API requests, and support for returning information on non-hosted add-ons.
Last edited by SilverWave; August 6th, 2011 at 08:46 AM. Reason: typo
Yes a new Betafirefox - 6.0~b5+build1+nobinonly-0ubuntu0.11.04.1~mfn1 (changes file) chrisccoulson 13 hours ago Published Natty Web Publishing details
firefox (6.0~b5+build1+nobinonly-0ubuntu0.11.04.1~mfn1) natty; urgency=low * New upstream release from the beta channel (FIREFOX_6_0b5_BUILD1)