The problem for non-Addon-SDK addons is that the "addons API" currently includes all details of the browser's user interface and all XPCOM objects. There is no separate API for addons; they have access to everything the browser itself has access to.
For addons built on the addon SDK, the API is in fact guaranteed to be stable; things are moving in that direction, but aren't there yet.
Browsers are a place where ongoing research into dynamic language optimization is happening, where ongoing modifications to the web's security model are happening, where typography features that the web hasn't had before are being added, where new defences against sites attempting to attack and exploit users are being added. This is not old tech.
> I want a browser that focuses on security and > standards compliance
"standards compliance" to most people means "add support for this spec here". As in, features.
> including technology that has gone through the whole > W3C standards process
This is he standards process where people giving feedback on the specs were explicitly told to shut up and go away, right? When they weren't just stonewalled in perpetuity?
Did you actually try participating in that process back then?
The W3C has gotten a bit better since, but there are plenty of terrible (not to mention self-contradictory, both within a single spec and between specs) specs with the W3C stamp on them out there. So just because it's a W3C recommendation doesn't mean much.
Heck, CSS2.0 is a W3C recommendation, and that spec can't actually be implemented as written!
> Firefox needs to stop calling this Firefox 5 and start > calling it just Firefox.
That's the idea, yes. None of Mozilla's announcements here have referred to Firefox 5; they've all just called it Firefox.
The one vestige of the old setup is the "5.0" on the download button on mozilla.com, but that's going away with Firefox 6.
> My initial thought would be to assume all > extensions will work and allow the community of > users to report broken extensions
That is _exactly_ what's being done with extensions hosted on addons.mozilla.org.
The problems are happening with various custom extensions people install from third parties (Google Toolbar) or have foisted on them, in the case of things like McAfee and Skype. Mozilla doesn't control compatibility checks for those extensions at all; they're in the extensions' own hands.
> Mozilla has quite a considerable PR capability, > particularly in the technical press
The technical press has a way or writing about what they want to write about, not what you ask them to write about. Has its good points and bad points.;)
> it would also cost Mozilla some of their domination > of the Firefox project.
That's not necessarily a problem; a bigger problem is that outside contributors seem to not be interested in nitty-gritty infrastructure stuff much...
> It would also require a less contemptuous attitude > towards fellow (potential) contributors.
That sentiment worries me a lot. From what I've seen in my neck of the woods (Gecko core code), Mozilla is pretty welcoming of contributors. Certainly compared to other open-source projects I've tried to contribute to. But maybe things are different in other parts of the project?
> Yes, it's very disturbing to hear that if you are a > business
Well, of course. That's perfectly understandable. But at that point it's a practical judgment, not a moral issue.;)
> Is there a for-pay Firefox which does provide > equivalent enterprise manageability as Internet > Explorer does?
There is not, unfortunately, in spite of several people trying to start such a project in the past... Maybe it or something similar will happen this time. It would be a really good idea.
> But hearing official Mozilla spokespeople say "we > don't care about the enterprise"
Please, please don't take things Asa says at face value. Just don't. He doesn't speak for Mozilla here. I realize you have to take my word for it at the moment, but he really doesn't.
The situation is basically what I said: we don't have the resources to do long-term support ourselves while continuing to stay competitive. We're trying to figure out how to address that. An ideal solution from our point of view would be a group of organizations (Linux distributions, large companies, others who need long-term support) taking over long-term support, with initial (and some ongoing, because code reviews have to happen) assistance from existing Mozilla developers. So far there seems to be a dearth of organizations willing to step up to do that, oddly.;)
> There's no description of what build system changes > and testing infrastructure changes are needed.
Indeed. The details weren't in the post in question.
> other small and tiny projects make them.
This is actually simpler to do for a smaller project, as it happens.
> Can the process be automated
It would have to be, yes. That's the nontrivial part.
> if so, what would the ongoing cost per release be?
Good question, but the claim here was that the initial cost is small.
> Most of the costs should be incurred in setting the > system up
Yes.
> the ongoing work should be very small - principally > checking that the correct files end in the correct > location with the correct permissions
The ongoing work is to, on every change to the code, run automated installer test and make sure the installer performs correctly. This would need to be automated (an additional initial cost) and would require additional testing resources (hardware, people setting up that hardware, etc).
The cost has in fact been estimated, several times. Unfortunately, it's been to high each time. You're welcome to search the mailing list archives for those discussions; I just posted a summary that came by recently, and _my_ limited minutes are better served doing something else instead of doing a search that you can do as well...
Is it disturbing to have an open-source project say "here's a population of users; we unfortunately don't have the resources to address their special needs at this point"?
And make no mistake: "business" (really, any situation in which updates have to be staged) users do have special needs.
Now the good news here is that the source is open; if a few large "business" users got together they should be able to do a long-term support release, just like Linux distributions have been doing already. Of course with IE they don't have to do that... so they may want the free lunch after all.
> For example, how much work would be involved in > making an MSI installer and allowing preferences to > be set as a group policy?
According to one of the Mozilla folks who looked into just the former, it needs build system changes, build and test infrastructure changes, additional test infrastructure resources, and ongoing QA time investment. That's not counting any ongoing maintenance that would need to happen.
Or did you mean doing something but not actually testing whether it works before releasing it with every release?
You're agreeing with the grandparent. Given current bandwidths, you have to use UDP streaming, because a TCP stream might suddenly stutter partway through due to a lost packet.
But the point is that if bandwidth were much higher, you could get the entire video in a few tens of seconds (lost packets, retransmissions, and all), after which you're not dependent on the network at all to view the video. So at that point missing packets can't affect your watching experience. And if you're in that situation, there's no reason to not use TCP for that initial download of the video.
Firefox 5 is compatible with 85+% of the addons on addons.mozilla.org... so I don't know about "most". Note that Firefox 4 is not compatible with 100% of those addons either.
Actually, Mozilla could just license the MP3 patents or the H.264 patents if all they cared about was their own exposure.
But that wouldn't help the patent restrictions on authors and such.
So the stance against patent-encumbered codecs is less about a level playing field for Linux than about a level playing field for all who would like to put content on the web. And that last part is in fact one of the core aspects of Mozilla's reason for existence.
Gecko does not support MP3 in HTML for exactly the same reason it doesn't support H.264 in : it's patent-encumbered and you have to pay licensing fees to use it.
In 6 years, when the MP3 patents expire, we'll see.
For what it's worth, browsers that implement WebGL do in fact have a shader validator that restricts what code you can run (e.g. no variable-length loops, etc).
Slashdot Mirror
> It wasn't so bad when they were updating relatively
> infrequently
That's why it didn't happen before. It's a lot of work, and there just wasn't the manpower to do it.
> Actually, Mozilla's default behavior is to disable and
> prevent the user from re-enabling extensions
That's the old behavior. The behavior for Firefox 5 is different for extensions hosted on addons.mozilla.org.
There is also talk of shipping the add-on compatibility reporter by default.
August 16, actually. https://wiki.mozilla.org/RapidRelease/Calendar#Future_branch_dates
The problem for non-Addon-SDK addons is that the "addons API" currently includes all details of the browser's user interface and all XPCOM objects. There is no separate API for addons; they have access to everything the browser itself has access to.
For addons built on the addon SDK, the API is in fact guaranteed to be stable; things are moving in that direction, but aren't there yet.
> Browsers are old tech.
Wish that were so.
Browsers are a place where ongoing research into dynamic language optimization is happening, where ongoing modifications to the web's security model are happening, where typography features that the web hasn't had before are being added, where new defences against sites attempting to attack and exploit users are being added. This is not old tech.
> I want a browser that focuses on security and
> standards compliance
"standards compliance" to most people means "add support for this spec here". As in, features.
> including technology that has gone through the whole
> W3C standards process
This is he standards process where people giving feedback on the specs were explicitly told to shut up and go away, right? When they weren't just stonewalled in perpetuity?
Did you actually try participating in that process back then?
The W3C has gotten a bit better since, but there are plenty of terrible (not to mention self-contradictory, both within a single spec and between specs) specs with the W3C stamp on them out there. So just because it's a W3C recommendation doesn't mean much.
Heck, CSS2.0 is a W3C recommendation, and that spec can't actually be implemented as written!
> Firefox needs to stop calling this Firefox 5 and start
> calling it just Firefox.
That's the idea, yes. None of Mozilla's announcements here have referred to Firefox 5; they've all just called it Firefox.
The one vestige of the old setup is the "5.0" on the download button on mozilla.com, but that's going away with Firefox 6.
> My initial thought would be to assume all
> extensions will work and allow the community of
> users to report broken extensions
That is _exactly_ what's being done with extensions hosted on addons.mozilla.org.
The problems are happening with various custom extensions people install from third parties (Google Toolbar) or have foisted on them, in the case of things like McAfee and Skype. Mozilla doesn't control compatibility checks for those extensions at all; they're in the extensions' own hands.
> Mozilla has quite a considerable PR capability,
> particularly in the technical press
The technical press has a way or writing about what they want to write about, not what you ask them to write about. Has its good points and bad points. ;)
> it would also cost Mozilla some of their domination
> of the Firefox project.
That's not necessarily a problem; a bigger problem is that outside contributors seem to not be interested in nitty-gritty infrastructure stuff much...
> It would also require a less contemptuous attitude
> towards fellow (potential) contributors.
That sentiment worries me a lot. From what I've seen in my neck of the woods (Gecko core code), Mozilla is pretty welcoming of contributors. Certainly compared to other open-source projects I've tried to contribute to. But maybe things are different in other parts of the project?
> Yes, it's very disturbing to hear that if you are a
> business
Well, of course. That's perfectly understandable. But at that point it's a practical judgment, not a moral issue. ;)
> Is there a for-pay Firefox which does provide
> equivalent enterprise manageability as Internet
> Explorer does?
There is not, unfortunately, in spite of several people trying to start such a project in the past... Maybe it or something similar will happen this time. It would be a really good idea.
> But hearing official Mozilla spokespeople say "we
> don't care about the enterprise"
Please, please don't take things Asa says at face value. Just don't. He doesn't speak for Mozilla here. I realize you have to take my word for it at the moment, but he really doesn't.
The situation is basically what I said: we don't have the resources to do long-term support ourselves while continuing to stay competitive. We're trying to figure out how to address that. An ideal solution from our point of view would be a group of organizations (Linux distributions, large companies, others who need long-term support) taking over long-term support, with initial (and some ongoing, because code reviews have to happen) assistance from existing Mozilla developers. So far there seems to be a dearth of organizations willing to step up to do that, oddly. ;)
> If Mozilla cared about this they could be calling for
> help from the community of admins out there
They have, several times. The answer was pretty deafening silence....
> There's no description of what build system changes
> and testing infrastructure changes are needed.
Indeed. The details weren't in the post in question.
> other small and tiny projects make them.
This is actually simpler to do for a smaller project, as it happens.
> Can the process be automated
It would have to be, yes. That's the nontrivial part.
> if so, what would the ongoing cost per release be?
Good question, but the claim here was that the initial cost is small.
> Most of the costs should be incurred in setting the
> system up
Yes.
> the ongoing work should be very small - principally
> checking that the correct files end in the correct
> location with the correct permissions
The ongoing work is to, on every change to the code, run automated installer test and make sure the installer performs correctly. This would need to be automated (an additional initial cost) and would require additional testing resources (hardware, people setting up that hardware, etc).
The cost has in fact been estimated, several times. Unfortunately, it's been to high each time. You're welcome to search the mailing list archives for those discussions; I just posted a summary that came by recently, and _my_ limited minutes are better served doing something else instead of doing a search that you can do as well...
Yeah, having a sufficiently broken feature, or one that you break with updates, is generally worse than not having it at all...
The bar for "sufficiently" sits at different places for different people and can move with time, of course.
> and then they download Chrome
Which also doesn't work at work?
Is it disturbing to have an open-source project say "here's a population of users; we unfortunately don't have the resources to address their special needs at this point"?
And make no mistake: "business" (really, any situation in which updates have to be staged) users do have special needs.
Now the good news here is that the source is open; if a few large "business" users got together they should be able to do a long-term support release, just like Linux distributions have been doing already. Of course with IE they don't have to do that... so they may want the free lunch after all.
> For example, how much work would be involved in
> making an MSI installer and allowing preferences to
> be set as a group policy?
According to one of the Mozilla folks who looked into just the former, it needs build system changes, build and test infrastructure changes, additional test infrastructure resources, and ongoing QA time investment. That's not counting any ongoing maintenance that would need to happen.
Or did you mean doing something but not actually testing whether it works before releasing it with every release?
Net Neutrality is not an absolute.
There's a big difference between prioritizing based on traffic _type_ and prioritizing based on traffic _destination_.
You're talking about the former. Most net neutrality advocates are concerned about the latter.
> And all traffic types of the same type (VOIP for
> example) shall be treated the same regardless of
> connection end-points.
Yep, I think this is exactly what we need.
"update" and "new version" is a false dichotomy, unfortunately. Security updates in the web world often involve functionality changes....
If your addon is on addons.mozilla.org, then it got checked for compat with Firefox 5 and automatically version-bumped if it was compatible.
If your addon is not on AMO, you don't need to worry about AMO's policies.
Google Toolbar, for example, is not on AMO.
For a bunch of stuff people want to do with tablets a 15" screen is actually too big. So the 12" screen may in fact be worth extra money to people.
You're agreeing with the grandparent. Given current bandwidths, you have to use UDP streaming, because a TCP stream might suddenly stutter partway through due to a lost packet.
But the point is that if bandwidth were much higher, you could get the entire video in a few tens of seconds (lost packets, retransmissions, and all), after which you're not dependent on the network at all to view the video. So at that point missing packets can't affect your watching experience. And if you're in that situation, there's no reason to not use TCP for that initial download of the video.
Firefox 5 is compatible with 85+% of the addons on addons.mozilla.org... so I don't know about "most". Note that Firefox 4 is not compatible with 100% of those addons either.
Your first mistake is thinking that Mozilla is primarily about selling a product to start with....
Actually, Mozilla could just license the MP3 patents or the H.264 patents if all they cared about was their own exposure.
But that wouldn't help the patent restrictions on authors and such.
So the stance against patent-encumbered codecs is less about a level playing field for Linux than about a level playing field for all who would like to put content on the web. And that last part is in fact one of the core aspects of Mozilla's reason for existence.
Gecko does not support MP3 in HTML for exactly the same reason it doesn't support H.264 in : it's patent-encumbered and you have to pay licensing fees to use it.
In 6 years, when the MP3 patents expire, we'll see.
For what it's worth, browsers that implement WebGL do in fact have a shader validator that restricts what code you can run (e.g. no variable-length loops, etc).