Defaulting add-ons to compatible
Justin Scott
I've written a draft feature page to address a lot of the add-on
compatibility issues we've seen since switching to rapid releases, and
I'd like to get feedback from add-on developers and platform developers
on it.
https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible
Specifically, what issues can you see arising from this, apart from
non-crashing false positives?
Thanks!
Justin
Bridget Almas
This sounds like a good idea to me, but I'd like clarification on the
automatic flagging of add-ons with binary components as incompatible.
Would this be limited in some way to XPCOM components, or would it apply
to all binaries? If the latter, I'd like to request that there to be a
way for add-on designers to flag add-ons with binary components as
default compatible (i.e. to override being automatically incompatible as
outlined in Stage 2, Design, Step 3).
The Alpheios add-ons include binaries but they aren't XPCOM components,
and so are usually not impacted by the upgrades.
Thanks
Bridget Almas
The Alpheios Project
http://alpheios.net
Hi,
https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible
Thanks!
Justin
_______________________________________________
dev-extensions mailing list
dev-ext...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-extensions
Tony Mechelynck
Here's my opinion as an extension user (46 enabled ones, IIRC, according
to the "Extensions" pane of the add-ons manager, in trunk nightlies of
SeaMonkey):
After reading the wiki page, it sounds like a nice idea: "it might
work". However I think that it would need extensive testing to ferret
out any unforeseen side-effects.
As for the notion that "anything without binary components cannot crash
the application", I remember that some years ago I was using Firefox
1.0.x (which was, at the time, the "current stable build") with a
certain 3rd-party theme, a theme mind you, not even an extension, but
that theme stopped being maintained; and someday, after upgrading to the
next Firefox version (1.1.0 maybe, or 1.5, my memory is hazy) it started
crashing regularly, until I enabled a different theme, and only then did
my crashes stop.
Best regards,
Tony.
--
In America today ... we have Woody Allen, whose humor has become so
sophisticated that nobody gets it any more except Mia Farrow. All
those who think Mia Farrow should go back to making movies where the
devil gets her pregnant and Woody Allen should go back to dressing up
as a human sperm, please raise your hands. Thank you.
-- Dave Barry, "Why Humor is Funny"
IDEVFH
In your outline, the following paragraph concern myself for binary
inclusions.
Stage 2: Design
5. Functional specification
When Firefox needs to determine an add-on's compatibility, it should do
the following:
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).
I could understand this for an XPCOM wrapping of the binary but other
supportive binaries ( .dlls or .exes ) within an add-on hosting - Why ?
If a binary is being functioned utilized with js-ctype for referencing
or execution of ( .dlls or .exes ) it makes no sense to flag the add-on
to be disabled. How will this conflict with Firefox code ?
Regards,
richard
or
IDEVFH
ide...@gmail.com
Mark Banner
> ozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible
>
> Specifically, what issues can you see arising from this, apart from
> non-crashing false positives?
I'm not sure I actually get the benefits of this over the current system.
If the compatibility code picks up an extension as incompatible, why
should we pretend it is compatible? What benefit does this actually give
to anyone?
Additionally, you say:
> 1. If the add-on is marked as compatible with the version, nothing needs to be done. The add-on remains enabled.
However, with the compatibility check bump, the add-on author doesn't
need to do anything here to remain enabled either. So whilst true, I
think this statement is slightly misleading in benefit terms.
I certainly find the idea interesting, just not sure I'm seeing what you do.
Mark.
Justin Scott
> On 02/08/2011 01:09, Justin Scott wrote:
>> ozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible
>>
>> Specifically, what issues can you see arising from this, apart from
>> non-crashing false positives?
>
> I'm not sure I actually get the benefits of this over the current system.
>
smaller percentage are compatible with the latest version in order to
continue on the bump train. When we planned the AMO bump system we
didn't know so many third-party add-ons were in use, and even if users
aren't using them or don't care about them, seeing that they are
incompatible will discourage them from updating to future versions.
> If the compatibility code picks up an extension as incompatible, why
> should we pretend it is compatible? What benefit does this actually give
> to anyone?
>
As the feature page says, the compatibility bumps will continue to be
run. If we know that an add-on is incompatible, it will be marked as
such and Firefox won't try to work around it.
custom.firefox.lady
"Justin Scott" <fli...@mozilla.com> wrote in message
news:4d2dnTTgi6aC3arT...@mozilla.org...
Regarding:
"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. "
The main issues I would expect
1. Firefox users blaming Firefox for incompatible add-ons that break Firefox
features (e.g. Add-ons Manager won't open, autocomplete doesn't work, fx
won't start)
2. Users blaming add-on authors for add-ons that don't work on fx version
which Mozilla wrongly declared compatible.
Isn't #1 a major reason we have compatibility checking? (Nightly testers are
often told to test with add-ons disabled to see whether a fx 'bug' is
actually caused by an extension.)
#2 can be managed by providing a method for add-on devs to mark add-on
version x incompatible with fx version y.
Also are we sure that add-ons without binary components can't crash fx? I
remember several years ago when I added the Boox-related feature to my
Stay-Open Menu extension, that it had to be done in a specific way, to avoid
crashing fx. Perhaps that's not applicable (it was with fx 3 and wasn't
related to an updated fx version) and I'm not saying you're wrong, just
asking whether it's certain not to crash fx, unlikely to, or whatever.
Benjamin Smedberg
>
> https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible
From the page:
> 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 is a dangerous assumption on two counts:
Firstly, as other have noted, it is quite possible for just JS/XUL code
to cause crashes. We try to be more defensive in APIs which are exposed
to chrome script, but there are lots of cases where malformed XUL/XBL
can hit weird edge cases which cause crashes. This is one of the primary
reasons we disabled XUL for web content.
Secondly, I challenge the assumption that crashes are our primary
concern. Anything which makes Firefox unusable is a big issue. Crashes
are mostly visible to us through crash-stats, but there are many ways
that an extension can make Firefox totally unusable without crashing it.
Many advanced extensions replace core components (in JS) in ways that
can easily break and cause Firefox to start without showing any windows,
or showing a single blank window. Incompatible themes can very easily
cause Firefox windows to be hidden or completely malformed.
I think that if we're going to go this route, we need to build some sort
of self-check into Firefox so that if it doesn't appear to have started
properly, we either prompt the user to restart with extensions disabled,
or just do it directly.
--BDS
Nils Maier
Even simple add-ons can break in unforeseeable ways due to breaking
changes.
Depending on what breaks (and where) the add-on may render parts of
the application unusable (e.g. certain services, especially everything
that hooks http channels/content policies, the Add-on Manager, urlbar
bindings, etc.) or even stop the browser from loading at all. I
already encountered all the mentioned issues in my own and/or third-
party add-ons in Firefox5, Beta6, Aurora7 and Nightly8, usually due to
one of the following:
- (new) reserved keywords (|enum|, etc.)
- |nsIJSON| changes in 7 (now re-implemented)
- |top| is read-only in window scopes (kinda)
- new built-in globals (in js module scope), such as |File|
- |nsIWorkerFactory| and corresponding class removed
- |xbl:readonly| property implemented (this also broke some toolkit
code, at least the non US layouts of date/time pickers and shipped
unnoticed)
- XUL/CSS changes, especially when the nesting level/path of an
accessed Node changes
Some add-ons were broken in a way that required to kill the process
and then safe-mode disabling the add-on in question.
While any "regular" add-on, js-only or not, is prone to breaking
changes, not even Jetpack add-ons are "safe". Basically Jetpack add-
ons have all the same compat issues as "regular" ones plus some new,
for example:
- Add-on SDK libraries do not ship with the browser, but with the add-
ons and hence might be outdated
- The javascript engine changes (reserved keywords/new globals)
- |require("chrome")| + attempts to access removed and/or changed
interfaces/classes.
- |require("windows")| + changed XUL trees/CSS
Right now there is no safe way to write forward compatible add-ons and
lots of breaking changes with each release. A default-compatible
policy would certainly cause more trouble than it create convenience.
Furthermore such a policy would only attempt to solve/mask problems
that were created by adopting the Chrome rapid-release process without
properly taking into account the differences in mozilla-land, such as
more powerful add-ons.
IMO this would be better addressed by not making each release a
"major" release, but have 3-4 "stable API" release before a "breaking
changes" release, so that add-on developers have more time to react.
Dave Townsend
> On 8/1/2011 8:09 PM, Justin Scott wrote:
> >
> > https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible
>
> From the page:
>
> > 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 is a dangerous assumption on two counts:
>
> Firstly, as other have noted, it is quite possible for just JS/XUL code
> to cause crashes. We try to be more defensive in APIs which are exposed
> to chrome script, but there are lots of cases where malformed XUL/XBL
> can hit weird edge cases which cause crashes. This is one of the primary
> reasons we disabled XUL for web content.
My opinion here is that if it is possible for the outdated extension to crash us in this was then it is possible for a compatible extension to do the same. I guess the extension wouldn't get marked compatible if the crash was 100% reproducible
> Secondly, I challenge the assumption that crashes are our primary
> concern. Anything which makes Firefox unusable is a big issue. Crashes
> are mostly visible to us through crash-stats, but there are many ways
> that an extension can make Firefox totally unusable without crashing it.
> Many advanced extensions replace core components (in JS) in ways that
> can easily break and cause Firefox to start without showing any windows,
> or showing a single blank window. Incompatible themes can very easily
> cause Firefox windows to be hidden or completely malformed.
I think I would actually say that themes should not be included in this. They have a much higher chance of being affected by UI changes between releases than overlays from extensions.
We could also extend the checks to not just include binary components, but if the add-on overrides any internal component then it doesn't get defaulted to compatible to mitigate against the risk from these cases.
> I think that if we're going to go this route, we need to build some sort
> of self-check into Firefox so that if it doesn't appear to have started
> properly, we either prompt the user to restart with extensions disabled,
> or just do it directly.
This seems like it could be a useful measure regardless, maybe included as a part of the work in https://wiki.mozilla.org/Support/Firefox_Features/Clean_up_user_profile where multiple crashes is used as a trigger to help users clean up their profile. A couple of other interesting things we might be able to do:
* When an overlay fails XML parsing send out an observer notification with its URL. The add-ons manager could determine which add-on includes that overlay and act accordingly.
* When a JS script throws an exception at its top level or fails syntax checking do something similar.
The problem is figuring out enough of a sanity check. Presumably we also only have to run this once after each application update though so maybe we can afford to be quite thorough.
What I don't think we really have is a good idea of how often an incompatible extension actually breaks the app in bad enough ways like this. Are you saying we should do this even if it is a remote possibility?
Philip Chee
> IMO this would be better addressed by not making each release a
> "major" release, but have 3-4 "stable API" release before a "breaking
> changes" release, so that add-on developers have more time to react.
Not that I disagree with you. However I don't see how you would be able
to do this as it is fundamentally incompatible with the rapid release
train model where new features land as soon as they are ready. Delaying
such landings in the name of '3-4 stable API' releases would negate most
of the advantages the release train was designed to bring to the Firefox
development process.
There was some talk previously about a LTS model where one out of every
3-4 releases would be a LTS version supported until the next LTS version
is cut. However that idea seems to have died off (or discouraged, or
ignored).
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
VanillaMozilla
completely for many users? That's a very bad choice either way, and I
don't have a good answer. Unfortunately, having only one currently
supported version instead of two can only make it worse.
I believe three requirements have been imposed:
1. All users up to date
2. Don't break or disable extensions (no nasty surprises for users)
3. Only one supported version
While I agree strongly with all of them, I don't see how it's possible
to meet all three.
