3 ms·

Can someone more knowledgeable describe why each new FF version breaks existing extensions? Can't FF have a more stable extension architecture? Edit: though th

by iwwr 15y ago

Can someone more knowledgeable describe why each new FF version breaks existing extensions? Can't FF have a more stable extension architecture? Edit: though the idea that enterprise is useless may be dangerous. Each new FF user is worth maybe pennies or nothing at all in revenue to Mozilla, while enterprise 'seats' can get a nice premium.

ch0wn 15y ago
In my experience, most extensions work just fine after an update without modifications even if they are marked as incompatible. The addon authors simply tend to set the version compatibility rather conservatively.
windsurfer 15y ago
The issue is usually the extension creator's fault. It's left up the developer to say what versions your extension is compatible with - and usually that's left to just the current version.
- MatthewPhillips 15y ago
  Sounds like Mozilla's fault to me.
- mbrubeck 15y ago
  For add-ons hosted by Mozilla, this is no longer left up to the developer. Mozilla will automatically scan add-ons for compatibility with new versions and update their metadata: http://blog.mozilla.com/addons/2011/04/19/add-on-compatibility-rapid-releases/ http://blog.mozilla.com/addons/2011/04/19/add-on-compatibili...
  - windsurfer 15y ago
    Oh that's so cool. It's been a while since I've worked on themes and extensions, so this is awesome news :D
owenmarshall 15y ago
A few thoughts. First, Fx extensions are required to expose the versions that they work for. In many cases after a release extensions will work pretty well and just need to have the "working versions" updated. Apart from that, I think the new development process (http://mozilla.github.com/process-releases/draft/development_overview/ http://mozilla.github.com/process-releases/draft/development...) makes it less likely that new versions will break extensions. The past Fx development model focused on cramming a ton of features in to the browser, then bumping the version number. This could be a pain because there were huge changes, extensions broke and were slow to be updated, users were nagged... The new approach is to ship on a schedule: if a change is good, it goes into the RC; if it isn't ready, it stays out. But this likely means that every "new version" won't contain nearly as many massive and possibly breaking changes. I think this should let extension developers keep up with development better.
tedmielczarek 15y ago
Firefox can have a more stable extension architecture, it's called the "Add-on SDK", formerly "Jetpack": https://addons.mozilla.org/en-US/developers/ https://addons.mozilla.org/en-US/developers/ It's very similar to Chrome's restricted extension APIs, which are the reason that Chrome extensions are not tied to a specific version. If you offer a restricted API, you just have to ensure that that API doesn't break between releases. The problem is with existing Firefox extensions, which are able to use any API in the Mozilla platform, and touch every bit of the Firefox UI. They are essentially executed as if they were part of the browser itself. This approach offers near-unlimited power (you can do anything the browser code can do!) but makes compatibility difficult, since any change to any API can potentially break extensions. Thus extensions have to specify a maximum version of Firefox that they are compatible with. This is both good and bad: it's good in that Firefox extensions are much more powerful than Chrome extensions, but it's bad in that the versioning and compatibility issues are a problem. For Firefox 5, all extensions hosted on addons.mozilla.org were run through a compatibility checker, and if they didn't use any APIs that were impacted in the 4.0 -> 5.0 update, they were marked as compatible with Firefox 5 without any action on the author's part. This helped a lot, but unfortunately there are also a lot of extensions out there that are not hosted on addons.mozilla.org (such as Google Toolbar and other toolbars installed by third-party software, as well as corporate addons).

by iwwr 15y ago

ch0wn 15y ago

In my experience, most extensions work just fine after an update without modifications even if they are marked as incompatible. The addon authors simply tend to set the version compatibility rather conservatively.

windsurfer 15y ago

The issue is usually the extension creator's fault. It's left up the developer to say what versions your extension is compatible with - and usually that's left to just the current version.

MatthewPhillips 15y ago
Sounds like Mozilla's fault to me.
mbrubeck 15y ago
For add-ons hosted by Mozilla, this is no longer left up to the developer. Mozilla will automatically scan add-ons for compatibility with new versions and update their metadata: http://blog.mozilla.com/addons/2011/04/19/add-on-compatibility-rapid-releases/ http://blog.mozilla.com/addons/2011/04/19/add-on-compatibili...
- windsurfer 15y ago
  Oh that's so cool. It's been a while since I've worked on themes and extensions, so this is awesome news :D

owenmarshall 15y ago

A few thoughts. First, Fx extensions are required to expose the versions that they work for. In many cases after a release extensions will work pretty well and just need to have the "working versions" updated. Apart from that, I think the new development process (http://mozilla.github.com/process-releases/draft/development_overview/ http://mozilla.github.com/process-releases/draft/development...) makes it less likely that new versions will break extensions. The past Fx development model focused on cramming a ton of features in to the browser, then bumping the version number. This could be a pain because there were huge changes, extensions broke and were slow to be updated, users were nagged... The new approach is to ship on a schedule: if a change is good, it goes into the RC; if it isn't ready, it stays out. But this likely means that every "new version" won't contain nearly as many massive and possibly breaking changes. I think this should let extension developers keep up with development better.

tedmielczarek 15y ago

Firefox can have a more stable extension architecture, it's called the "Add-on SDK", formerly "Jetpack": https://addons.mozilla.org/en-US/developers/ https://addons.mozilla.org/en-US/developers/ It's very similar to Chrome's restricted extension APIs, which are the reason that Chrome extensions are not tied to a specific version. If you offer a restricted API, you just have to ensure that that API doesn't break between releases. The problem is with existing Firefox extensions, which are able to use any API in the Mozilla platform, and touch every bit of the Firefox UI. They are essentially executed as if they were part of the browser itself. This approach offers near-unlimited power (you can do anything the browser code can do!) but makes compatibility difficult, since any change to any API can potentially break extensions. Thus extensions have to specify a maximum version of Firefox that they are compatible with. This is both good and bad: it's good in that Firefox extensions are much more powerful than Chrome extensions, but it's bad in that the versioning and compatibility issues are a problem. For Firefox 5, all extensions hosted on addons.mozilla.org were run through a compatibility checker, and if they didn't use any APIs that were impacted in the 4.0 -> 5.0 update, they were marked as compatible with Firefox 5 without any action on the author's part. This helped a lot, but unfortunately there are also a lot of extensions out there that are not hosted on addons.mozilla.org (such as Google Toolbar and other toolbars installed by third-party software, as well as corporate addons).