Proposal for reducing the use of extension compatibility overrides
Dave Townsend
that QA, developers and nightly testers can use to test the product with
extensions that have yet to be updated with the development builds. The
extensions.checkCompatibility preference. It is also often advertised to
users letting them take up new versions of Firefox early and still use
their must-have extensions that haven't been updated yet. However it
carries a risk. Incompatible extensions can cause anything from minor UI
oddities to full blown crashes of the product.
Right now this pref is more "set and forget". A user may do it
immediately after installing Firefox 3 and then months later can still
be installing extensions that are incompatible without knowing it, and
importantly not associating it with the cause of problems.
I would like to suggest that we move to resetting
extensions.checkCompatibility whenever a user installs a new version of
Firefox, by which I mean an update that changes the version number, this
would not affect mere nightly updates (except where they move from
3.1a1pre to 3.1a2pre for example).
Hopefully for many regular users the extensions they needed the pref for
will have been updated by the time 3.1.1 is out. If not, and for
developers and testers, it is simply a matter of toggling the pref in
about:config again (I don't think we should re-hide the preference in
this case). This should mean that users only have the preference set if
they actually need it and reduce the number of people just blindly
running with it and getting problems from incompatible extensions.
I'm interested to know what others think of this plan before I start to
work on implementing it.
Dave
Axel Hecht
installed extensions are upgraded to a compatible version? Kinda like
"once you're good, don't go back to bad".
Doing that at app upgrade time sounds like not the best timing.
Axel
Basil Hashem
> I'm wondering, could we set that toggle on the occasion that all
> installed extensions are upgraded to a compatible version? Kinda like
> "once you're good, don't go back to bad".
This condition may never be met due to various factors such as
disabled add-ons, pending updates, pending uninstalls, cancelled
updates, locally installed add-ons, no update available add-ons,
etc...add-ons have many states in the Add-ons Manager.
I'm very supportive of this plan as I believe it:
- Will reduce crashiness and bad UX (esp for unsuspecting users)
- Will discourage indiscriminate and uninformed compatibility
- May encourage add-on developers to get compatibility faster
And it's not hard to reset it back to false by devs, beta testers,
etc...while protecting a larger subset of the Firefox user base.
-Basil
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
--
Basil Hashem
ba...@mozilla.com
John J Barton
> We currently have the pretty useful extensions.checkCompatibility pref
> that QA, developers and nightly testers can use to test the product with
> extensions that have yet to be updated with the development builds. The
> extensions.checkCompatibility preference. It is also often advertised to
> users letting them take up new versions of Firefox early and still use
> their must-have extensions that haven't been updated yet. However it
> carries a risk. Incompatible extensions can cause anything from minor UI
> oddities to full blown crashes of the product.
Thanks for reminding me about this. I can suggest it to Firefox 2 users
who want to use Firebug 1.2.
I think the reality is that compatible extensions can cause anything
from minor UI oddities to full blown crashes. The most likely result
from loading an so-called incompatible extension is that the extension
fails. Really the extension isn't incompatible, it is just slightly out
of date.
>
> I would like to suggest that we move to resetting
> extensions.checkCompatibility whenever a user installs a new version of
> Firefox, by which I mean an update that changes the version number, this
> would not affect mere nightly updates (except where they move from
> 3.1a1pre to 3.1a2pre for example).
I think resetting user-set configurations is never good. If you must,
then tell them and allow them to opt out.
We need better support for extensions, not more ways to make them hard
to use.
John
chris hofmann
Basil Hashem wrote:
> On Jul 18, 2008, at 3:49 PM, Axel Hecht wrote:
>
>
>> I'm wondering, could we set that toggle on the occasion that all
>> installed extensions are upgraded to a compatible version? Kinda like
>> "once you're good, don't go back to bad".
>>
>
> This condition may never be met due to various factors such as
> disabled add-ons, pending updates, pending uninstalls, cancelled
> updates, locally installed add-ons, no update available add-ons,
> etc...add-ons have many states in the Add-ons Manager.
>
> I'm very supportive of this plan as I believe it:
> - Will reduce crashiness and bad UX (esp for unsuspecting users)
> - Will discourage indiscriminate and uninformed compatibility
> - May encourage add-on developers to get compatibility faster
>
> And it's not hard to reset it back to false by devs, beta testers,
> etc...while protecting a larger subset of the Firefox user base.
>
> -Basil
>
>
yeah, most of our top crashes over the firefox 3 betas were related to
people turning off compatibility checking of extensions, then not
understanding the abnormal number of crashes and instability they were
seeing were the result of extensions that were not compatible. we
have definite evidence that many users were not correlating their action
to turn of compat checking with the problems they were experiencing.
we suffered from a lot of bad general advice like this spread around
blogs and press
http://www.megaleecher.net/taxonomy/term/2323
and then ended up with a lot of problems just like this
https://bugzilla.mozilla.org/show_bug.cgi?id=422018
during the firefox 3 development cycle.
this is a good plan to help combat that problem, give everyone a better
experience testing and using new versions, and reduce the noise we see
in crash data.
we should go with it.
-chofmann
>> _______________________________________________
>> dev-planning mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-planning
>>
>
> --
> Basil Hashem
> ba...@mozilla.com
>
>
>
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
John J Barton
...
> yeah, most of our top crashes over the firefox 3 betas were related to
> people turning off compatibility checking of extensions, then not
> understanding the abnormal number of crashes and instability they were
> seeing were the result of extensions that were not compatible. we
> have definite evidence that many users were not correlating their action
> to turn of compat checking with the problems they were experiencing.
>
> we suffered from a lot of bad general advice like this spread around
> blogs and press
> http://www.megaleecher.net/taxonomy/term/2323
>
> and then ended up with a lot of problems just like this
> https://bugzilla.mozilla.org/show_bug.cgi?id=422018
>
> during the firefox 3 development cycle.
>
Wait, that just a great argument for *not* changing the settng. The bug
reports were during 3.0b4, exactly the time you want lots of crashes!
I do think it makes sense to divide extensions in to Javascript-only and
dll-containing piles. Then apply different approaches to these groups,
since the impact of incompatibility is so different. You want the JS
only extensions to probe the platform during beta tests, compatible or not.
John
Zack Weinberg
> Dave Townsend wrote:
> > I would like to suggest that we move to resetting
> > extensions.checkCompatibility whenever a user installs a new
> > version of Firefox, by which I mean an update that changes the
> > version number, this would not affect mere nightly updates (except
> > where they move from 3.1a1pre to 3.1a2pre for example).
>
> I think resetting user-set configurations is never good. If you must,
> then tell them and allow them to opt out.
>
> We need better support for extensions, not more ways to make them
> hard to use.
I concur.
If someone's gone and disabled compatibility checking so they can
install an extension on an allegedly unsupported version of the
browser, then that extension is important to them, and they're likely
to upgrade the browser again. And if they have to go and reset the
pref every time they upgrade it's just going to irritate them.
zw
chris hofmann
John J Barton wrote:
> chris hofmann wrote:
> ...
>
>> yeah, most of our top crashes over the firefox 3 betas were related to
>> people turning off compatibility checking of extensions, then not
>> understanding the abnormal number of crashes and instability they were
>> seeing were the result of extensions that were not compatible. we
>> have definite evidence that many users were not correlating their action
>> to turn of compat checking with the problems they were experiencing.
>>
>> we suffered from a lot of bad general advice like this spread around
>> blogs and press
>> http://www.megaleecher.net/taxonomy/term/2323
>>
>> and then ended up with a lot of problems just like this
>> https://bugzilla.mozilla.org/show_bug.cgi?id=422018
>>
>> during the firefox 3 development cycle.
>>
>>
>
> Wait, that just a great argument for *not* changing the settng. The bug
> reports were during 3.0b4, exactly the time you want lots of crashes!
>
>
Actually we should be trying to get more stable every day, every
release... ;-)
If we do want to understand possible stability problems earlier rather
than later as I think you are suggesting, then we want lots of
"interesting" crashes. We actually don't want the crash reporting
system, and analysis time jambed up with top crashes for known
incompatibility problems. In this case, and with many others, the
extension was known to not be compatible, the version number for the
extension was *not* bumped intensionally to try and avoid all the extra
noise, but we got it anyway because of a lot of bad advice floating
around saying that it was really ok to turn of checking.
If an extension developer thinks thier extension is ready for a lot of
use during a beta test period they should bump the version number, get
the old extension (or the latest update) out in use.
If we do things this way we are using the system as designed; we will
be using the version info to check compatibility.
> I do think it makes sense to divide extensions in to Javascript-only and
> dll-containing piles. Then apply different approaches to these groups,
> since the impact of incompatibility is so different. You want the JS
> only extensions to probe the platform during beta tests, compatible or not.
>
>
maybe, but why wouldn't you want to just bump the version number so show
compatibility with binary or js extensions?
That should be the sign you should be using to express compatibility of
all types...
> John
John J Barton
...
> If an extension developer thinks thier extension is ready for a lot of
> use during a beta test period they should bump the version number, get
> the old extension (or the latest update) out in use.
The basic problem is that the only practical way many extension
developers have to find out if there are compatibility problems is from
user reports.
Consider Firebug. Suppose we released with max version 3.0 because we
have not tested with 3.0.1. Then 3.0.1 comes out. Everyone is mad.
Does that mean 3.0.* is the answer? Well: suppose 2.0.0.16 comes out and
our max is 3.0.*. Does that mean it works with 2.0.0.16? No, and in fact
it does not. How do I know? User told me.
John.
Zack Weinberg
> ...
> > If an extension developer thinks thier extension is ready for a lot
> > of use during a beta test period they should bump the version
> > number, get the old extension (or the latest update) out in use.
>
> The basic problem is that the only practical way many extension
> developers have to find out if there are compatibility problems is
> from user reports.
This just made me think of an alternative approach. We already have
the "Firefox appears to have crashed, do you want to try to recover
your tabs?" dialog box. How about detecting when a crash is likely to
have been caused by an extension, and offering to guide the user
through a series of tests, disabling extensions one at a time until the
offending one is identified, and then (a) blacklists that extension
until upgraded, (b) auto-files a bug report?
zw
chris hofmann
Zack Weinberg wrote:
> John J Barton <johnj...@johnjbarton.com> wrote:
>
>> chris hofmann wrote:
>> ...
>>
>>> If an extension developer thinks thier extension is ready for a lot
>>> of use during a beta test period they should bump the version
>>> number, get the old extension (or the latest update) out in use.
>>>
>> The basic problem is that the only practical way many extension
>> developers have to find out if there are compatibility problems is
>> from user reports.
>>
>
> This just made me think of an alternative approach. We already have
> the "Firefox appears to have crashed, do you want to try to recover
> your tabs?" dialog box.
> How about detecting when a crash is likely to
> have been caused by an extension,
this is similar to
https://bugzilla.mozilla.org/show_bug.cgi?id=411425#c2 but a bit more
invovled.
at the time of the crash when the dialog comes up we don't know the
cause of the crash. the crash report needs to be process, then
categorized, then connected to the right bits of information that would
help the user to diagnose in detail, or get involved with the
investigation on a particular stack signature. we would have to do all
that before we might be able to follow though with the rest of what your
suggesting below.
at any given time there is only investigation going on on 20-30 of
hundreds or thousands of stack signatures in the current set up and
community that looks at crash data, but this would be a way to get more
people involved by making participation easier.
> and offering to guide the user
> through a series of tests, disabling extensions one at a time until the
> offending one is identified, and then (a) blacklists that extension
> until upgraded, (b) auto-files a bug report?
>
>
this is a good idea, but there are a lot more basic functions we need in
the current crash reporting system before we try to go after something a
bit more complex like this.
> zw
Justin Dolske
> Hopefully for many regular users the extensions they needed the pref for
> will have been updated by the time 3.1.1 is out. If not, and for
> developers and testers, it is simply a matter of toggling the pref in
> about:config again
It sounds like a reasonable idea in general.
But one issue would seem to limit its effectiveness... Some users are
going to notice that their extensions became incompatible, and will just
immediately flip the pref back to re-enable them. So, no gain.
Other users won't notice, or won't remember how to to flip the pref
back. Here there's at least some hope they will either do nothing or
notice their browser is more stable. That's probably optimistic, though:
without a clear cause-and-effect (like a dialog saying the browser
crashed because of Extension Foobar, and would-you-like-to-disable-it),
I'm not sure people will make the association.
This might be most useful just for major-version updates. I would assume
some number of people enabled the pref in Firefox 2 immediately after
release (so that their 1.5-only extensions kept working), and are now
unintentionally being bitten by that when upgrading to Firefox 3.
Justin
Tanner Young
> the "Firefox appears to have crashed, do you want to try to recover
> your tabs?" dialog box. How about detecting when a crash is likely to
> through a series of tests, disabling extensions one at a time until the
> offending one is identified, and then (a) blacklists that extension
> until upgraded, (b) auto-files a bug report?
Perhaps, we could add a "Restart Firefox in Safe Mode" option after a crash. This would allow a user to disable settings known to cause crashes, specifically add-ons.
Users could disable add-ons at that point and diagnose if one is faulty, and testers and extension developers wouldn't lose their compatibility check setting.
Another thought is that extension compatibility issues tend to occur immediately after a user installs a major update and manually overwrites their compatibility check. Perhaps we could have a notice in the crash dialogue only for users with this setting off informing them that the crash might have been caused by an extension. This wouldn't apply to individuals who had their compatibility check turned on, and therefore prevent some confusion.
Just a suggestion,
Tanner Young
John J. Barton
> Another thought is that extension compatibility issues tend to occur immediately after a user installs a major update and manually overwrites their compatibility check. Perhaps we could have a notice in the crash dialogue only for users with this setting off informing them that the crash might have been caused by an extension. This wouldn't apply to individuals who had their compatibility check turned on, and therefore prevent some confusion.
But I think the compatibility test could be *causing* this behavior in
the first place.
I am assuming that the vast majority of extensions are Javascript only.
Is there any data on this? (And as I said think binary extension ought
to be treated differently).
For Javascript-only Firefox should not crash no matter what the
extension tries to do. But, of course, extension do things to the
Firefox API that the base code does not do, so new crashes appear when
extensions are run. These are still Firefox bugs.
By having compatibility tests during the beta, many extensions get only
light use during beta tests. Then when the major update lands,
extensions come out of the woodwork and get blamed for what is really a
problem in the total solution.
Without the compatibility test, there could be a smooth transition as
more users try the new platform. The extensions that cannot work with
the next major update would get tested and either upgraded or their
issues would be public knowledge.
Zack Weinberg
> Zack Weinberg wrote:
> > How about detecting when a crash is likely to
> at the time of the crash when the dialog comes up we don't know the
> cause of the crash. the crash report needs to be process, then
> categorized, then connected to the right bits of information that
> would help the user to diagnose in detail, or get involved with the
> investigation on a particular stack signature. we would have to do
> all that before we might be able to follow though with the rest of
> what your suggesting below.
I had something much cruder in mind: if (a) firefox crashed, and (b)
there are extensions active in the profile, then go into a mode where
we try disabling extensions one at a time and asking the user to
attempt to reproduce the crash. It seems to me that the trickiest thing
here would be the user interface for guiding the user through testing.
zw
Robert Kaiser
> I would like to suggest that we move to resetting
> extensions.checkCompatibility whenever a user installs a new version of
> Firefox, by which I mean an update that changes the version number, this
> would not affect mere nightly updates (except where they move from
> 3.1a1pre to 3.1a2pre for example).
Would it be possible to create some integrated feature in EM that cares
about this in more detail? I.e. if EM detects the add-on the user tries
to install is not campatible, offer in some way, with enough warning, a
way to set an exception for _this_ version of _this_ extension only, and
flagging activated-through-exception versions in a way in the EM display
that it strikes out?
We're doing something similar for bad SSL keys in the browser, and I
think such a solution is way better than a general "don't check for
problems" pref (I'd even vote for removing that completely if such a
specific-exception system is implemented).
Such a system would lead to people not being able to forget the setting
and install other incompatible add-ons without realizing it, as they get
heavy warnings for every such add-on and need to go through a careful
process to only accept that one version.
This should also be saved in a way that the exception is being killed
when a new version comes out or we poll AMO and realize it's now marked
compatible.
Robert Kaiser
Basil Hashem
> only.
> Is there any data on this? (And as I said think binary extension ought
> to be treated differently).
I did an analysis of add-ons hosted on AMO awhile back and found about
10% of add-ons include a binary component.
--
Basil Hashem
ba...@mozilla.com
Philip Reames
wrong, but isn't there already an extension that provides this
functionality for Firefox (MR Tech Toolkit 6.0.1)? Maybe we could move
some of that code into the core extension manager?
One modification I would make to your proposal is to not allow overrides
by default. Instead, have a (non-hidden) perference somewhere in the
options that enables the UI. By default, it should probably be hidden
to protect users from themselves. The one exception to this would be
while upgrading to a new version. Then the UI would be enabled for
existing extensions only.
Yours,
Philip Reames
Mike Beltzner
> If someone's gone and disabled compatibility checking so they can
> install an extension on an allegedly unsupported version of the
> browser, then that extension is important to them, and they're likely
> to upgrade the browser again. And if they have to go and reset the
> pref every time they upgrade it's just going to irritate them.
That assertion is based on a somewhat reasonable assumption that users
understand that disabling the compatibility checking can result in a crash.
We saw, quite clearly, that this is not the case around ship-time. In
fact, many blogs and even a few news publications provided instrucions
to disable compatibility checking under the heading of "How to Make Your
Add-Ons Work with Firefox 3". Those users will flip the pref, at which
point it will be flipped forever - and could lead to instabilty at some
point down the road.
I like Dave's plan, though think that we can make things even a little
nicer for the user by telling them what has happened in cases where
flipping that pref will result in some add-ons being disabled (ie: we
detect that there are incompatibilities).
I would suggest we take Dave's plan, with the following UI:
Scenario: user has turned off compatibility checking, upgrades their
browser.
Case A: with the upgrade, all add-ons are detected as being compatible
- turn compatibility checking back on
Case B: with the upgrade, some add-ons are detected as being incompatible
- turn compatibility checking back on
- inform the user that after the recent browser upgrade, some add-ons
are not compatible with this new version (list them, if possible) and to
safeguard performance and stability, compatibility checking has been
re-enabled
I do not think we should put a "turn off compatibiltiy checking" button
on this UI as it would turn this dialog into a "whatever" notification.
I am also pretty sure most of the work is done here (aside from creating
a different string to use in the case where we're turning off
compatibility checking) since we already have a "these add-ons are
incompatible" dialog on upgrade.
cheers,
mike
John J. Barton
...
> We saw, quite clearly, that this is not the case around ship-time. In
> fact, many blogs and even a few news publications provided instrucions
> to disable compatibility checking under the heading of "How to Make Your
> Add-Ons Work with Firefox 3". Those users will flip the pref, at which
> point it will be flipped forever - and could lead to instabilty at some
> point down the road.
These users have clearly and purposefully gone to extra work to put
Firefox into a usable state. Now you want to undo their work to make
your crash stats look better?
I also don't understand why you are characterizing the blogs that are
providing information to Firefox users as somehow evil or at least
misguided. Yes, some users will flip the pref and later Firefox will
crash because of an extension. But lots of users will get a lot of use
of out addons that work fine. These are legitimate and practical
resources valuable to the community.
John.
Zack Weinberg
> At 7/19/2008 4:19 PM, Robert Kaiser wrote:
> > Would it be possible to create some integrated feature in EM that
> > cares about this in more detail? I.e. if EM detects the add-on the
> > user tries to install is not campatible, offer in some way, with
> > enough warning, a way to set an exception for _this_ version of
> > _this_ extension only, and flagging activated-through-exception
> > versions in a way in the EM display that it strikes out?
> > We're doing something similar for bad SSL keys in the browser, and
> > I think such a solution is way better than a general "don't check
> > for problems" pref (I'd even vote for removing that completely if
> > such a specific-exception system is implemented).
This idea sounds good to me, for the record. It could also feed into
my earlier proposal of detecting troublesome extensions post-crash; any
extension marked as forcibly enabled is a prime candidate for
post-crash disable testing.
> One modification I would make to your proposal is to not allow
> overrides by default. Instead, have a (non-hidden) perference
> somewhere in the options that enables the UI. By default, it should
> probably be hidden to protect users from themselves.
but I don't like this at all, and would like to suggest that, in
general, anything whose primary rationale is "to protect users from
themselves" is a bad idea. We shouldn't ever be making the computer
assume the user is a moron; a disrespectful user experience is a bad
user experience.
zw
Zack Weinberg
> Zack Weinberg wrote:
> > If they have to go and
> > reset the pref every time they upgrade it's just going to irritate
> > them.
>
> That assertion is based on a somewhat reasonable assumption that
> users understand that disabling the compatibility checking can result
> in a crash.
>
> fact, many blogs and even a few news publications provided
> instrucions to disable compatibility checking under the heading of
> "How to Make Your Add-Ons Work with Firefox 3". Those users will flip
> the pref, at which point it will be flipped forever - and could lead
> to instabilty at some point down the road.
Well, then, the cure is not to go and reset the pref behind their back,
but to make the consequences of the action clear at the time the action
is taken. I like Robert's suggestion of exposing the compatibility
override in the extension manager UI on a per-extension basis. That
then gives us the opportunity to educate the user, and additional
information that can be used to do smart things if the browser
does crash. But we shouldn't go resetting the per-extension pref,
either, unless the extension itself is upgraded and changes its stated
support range.
John Barton's suggestion of distinguishing extensions with binary
components from pure JS extensions also makes sense to me; we could,
at least, use it to tailor the strength of the warnings (change "might
cause instability" to "is likely to cause instability" for instance).
I understand that we want a smooth user experience for people who don't
think much about these things, but I think it's also very important not
to piss off the people who *do* think about these things; those people
are in some sense our core constituency. They are more likely to write
blog reviews, decide whether major web frameworks will support our
features, and so on - things that apply leverage one way or the other
to our mindshare.
zw
Mike Beltzner
<johnj...@johnjbarton.com> wrote:
> Mike Beltzner wrote:
> ...
>> We saw, quite clearly, that this is not the case around ship-time. In
>> fact, many blogs and even a few news publications provided
>> instrucions
>> to disable compatibility checking under the heading of "How to Make
>> Your
>> Add-Ons Work with Firefox 3". Those users will flip the pref, at
>> which
>> point it will be flipped forever - and could lead to instabilty at
>> some
>> point down the road.
>
> These users have clearly and purposefully gone to extra work to put
> Firefox into a usable state. Now you want to undo their work to make
> your crash stats look better?
That's certainly one way to look at it. Another way is to say that
users who turned it on because they:
- were early adopters who were willing to take some risk during the RC
stage,
- were told to do so by a trusted friend who knew that the add-ons in
question were indeed stable
shouldn't be at increased risk the next time they update their browser
just because of a decision made months or even years prior.
> I also don't understand why you are characterizing the blogs that are
> providing information to Firefox users as somehow evil or at least
> misguided.
That's not what I said at all - I said that the information wasn't
only provided for testers, nor was it often accompanied with
information about the increased risk. Most often, it was listed as
"here's how to get your add-ons to work".
> Yes, some users will flip the pref and later Firefox will
> crash because of an extension. But lots of users will get a lot of
> use
> of out addons that work fine. These are legitimate and practical
> resources valuable to the community.
Which is why they can make informes decisions about the risk and
disable the check again. All I'm saying is that when the risk profile
changes, we need to inform users.
cheers,
mike
chris hofmann
John J. Barton wrote:
> Mike Beltzner wrote:
> ...
>
>> We saw, quite clearly, that this is not the case around ship-time. In
>> fact, many blogs and even a few news publications provided instrucions
>> to disable compatibility checking under the heading of "How to Make Your
>> Add-Ons Work with Firefox 3". Those users will flip the pref, at which
>> point it will be flipped forever - and could lead to instabilty at some
>> point down the road.
>>
>
> These users have clearly and purposefully gone to extra work to put
> Firefox into a usable state.
No, these users are just following what sounds like good advice.
> Now you want to undo their work to make
> your crash stats look better?
>
Thats one effect. Having Firefox work better for a lot of people that
are not understanding the ramifications of there actions is the primary
goal. Sending a signal that its time to be cautious about compatibility
issues is the communication mechanism that we don't have and one that we
need.
You mentioned earlier your concern about doing this flipping during
minor version updates (2.0.0.15 to 2.0.0.16, or 3.0.1 to 3.0.2. dcamp
should clearify, but I don't think that is part of the proposal. In
these minor upgrades there is a goal of maintaining compatibility and
thus no need to send this signal and revert the state of the pref.
> I also don't understand why you are characterizing the blogs that are
> providing information to Firefox users as somehow evil or at least
> misguided. Yes, some users will flip the pref and later Firefox will
> crash because of an extension. But lots of users will get a lot of use
> of out addons that work fine.
That is why the pref is there, and users can reset it. We are not
talking about removing the pref.
When there is a high likelihood of incompatibility introduced as we go
from alphas, to betas, to beta, to final releases we need a way to send
a signal for users to recheck the base state of the product and ensure
its working correctly; then move on to checking the state of extensions
by enabling one at time, or enabling them all and watching the impact.
That's the most prudent path for testing the browser and extensions
during development periods and makes the best use of everyones time and
effort. That path is preserved and re-enforced with this change.
> These are legitimate and practical
> resources valuable to the community.
>
>
Absolutely. Lets make the best use of everyones time and effort and not
allow a lot of people to get into a state where they don't know why
there browser is unstable or can't effectively participate in testing.
-chofmann
> John.
Mike Beltzner
> Well, then, the cure is not to go and reset the pref behind their back,
Had I proposed that we do it "behind their back" this would be a valid
critique. I think the point you're trying to make is that it may be
unexpected to have a preference reset to the default value on the
upgrade of the browser.
An alternative proposal (made by Shaver and others around the time this
was becoming an issue for Firefox 3 ship) was to have a per-version
pref. So you'd have
extension.checkCompatibility.2.0.x
extension.checkCompatibility.3.0.x
extension.checkCompatibility.3.1.x
&c
This would have the advantage of making things more clear (in a pretty
horrible way) at selection time, and still protecting users who set the
pref to acheive a desirable result for version N without realizing that
they may be pooching themselves for version N+1.
> but to make the consequences of the action clear at the time the action
> is taken. I like Robert's suggestion of exposing the compatibility
We could easily do so by making this a user-facing pref in the
Preferences pane. I don't think that's ever been the intent for this
issue, and it feels to me that we're solving this on the wrong end at
that point, and instead we should be making compatibility something
that's easier for add-on authors to manage instead of pushing this all
onto the beleagured user.
> override in the extension manager UI on a per-extension basis. That
> then gives us the opportunity to educate the user, and additional
I don't see how per-extension makes it easier to educate the user. How
will this solve the problem of the user realizing that setting the value
at one time means potential instability when they next upgrade their
browser, as well as potential instability at the time of the choice?
> information that can be used to do smart things if the browser
> does crash. But we shouldn't go resetting the per-extension pref,
> either, unless the extension itself is upgraded and changes its stated
> support range.
Having proper blame for crashes isn't, IMO, the primary goal. The
primary goal is to reduce the number of crashes and to ensure that those
who are at risk of add-on instability are at that risk voluntarily.
I don't understand the second point; if the extension itself is rated as
compatible, then there will be no interruption to the user's experience.
The add-on will continue to work with or without the compatibility check
override.
> John Barton's suggestion of distinguishing extensions with binary
> components from pure JS extensions also makes sense to me; we could,
> at least, use it to tailor the strength of the warnings (change "might
> cause instability" to "is likely to cause instability" for instance).
Do we know that's true? I think we'd rather build a more solid way of
determining this, perhaps by being able to discern which add-ons are
employing use of FUEL or other guaranteed APIs.
There's a lot we *could* do here, but in the interest of getting rolling
on something which we know we *should* do, I'm going to say that Dave's
proposal is a solid first step which can easily be extended and evolved
to include all of these much better steps.
> I understand that we want a smooth user experience for people who don't
> think much about these things, but I think it's also very important not
> to piss off the people who *do* think about these things; those people
> are in some sense our core constituency. They are more likely to write
> blog reviews, decide whether major web frameworks will support our
> features, and so on - things that apply leverage one way or the other
> to our mindshare.
This is a common refrain, but not one that I think is entirely valid. As
long as we inform them why this is happening, and only do it at major
version bumps, I think they'll understand that the value to end-users is
stronger. There are costs to using unreleased software, and this is
simply one of them - we're not disabling the functionality nor even
really making it more complex. Just asking people to confirm decisions.
cheers,
mike
Mike Beltzner
> You mentioned earlier your concern about doing this flipping during
> minor version updates (2.0.0.15 to 2.0.0.16, or 3.0.1 to 3.0.2. dcamp
> should clearify, but I don't think that is part of the proposal. In
It's Dave Townsend (Mossop) who proposed it, and the originally proposal
indeed states that the pref would be maintained across security and
stability updates. That has been what I've been supporting. Obviously to
do this on minor updates would be super-annoying and of limited use, as
add-ons should not be breaking across those updates.
cheers,
mike
Robert Strong
Mike Beltzner wrote:
> Case B: with the upgrade, some add-ons are detected as being incompatible
> - turn compatibility checking back on
> - inform the user that after the recent browser upgrade, some add-ons
> are not compatible with this new version (list them, if possible) and to
> safeguard performance and stability, compatibility checking has been
> re-enabled
>
They are listed already in the add-on update wizard displayed on first run per profile after an app upgrade. They will also be listed in the Add-ons mgr as disabled and incompatible after the app starts up since the checkCompatibility pref would be reset.
John J. Barton wrote:
> These users have clearly and purposefully gone to extra work to put
> Firefox into a usable state. Now you want to undo their work to make
> your crash stats look better?
>
To make crash stats look better? I'd say no as far as it being a reason to do this. To prevent crashes, improve the user experience, lessen the noise, etc.? I'd say yes.
> I also don't understand why you are characterizing the blogs that are
> providing information to Firefox users as somehow evil or at least
> misguided. Yes, some users will flip the pref and later Firefox will
> crash because of an extension. But lots of users will get a lot of use
> of out addons that work fine. These are legitimate and practical
> resources valuable to the community.
>
If the blog doesn't provide the caveat that flipping the pref has a risk then I'd characterize them as misinforming by leaving out important information... I wouldn't say they were evil but if they don't make that abundantly clear then they are most certainly not good from my point of view.
Robert
Justin Dolske
> It's Dave Townsend (Mossop) who proposed it, and the originally proposal
> indeed states that the pref would be maintained across security and
> stability updates.
Actually, my read of the original post was that the pref would be reset
on any version change (3.1a1 -> 3.1a2 being the example). I'd assume
it's just a small refinement to only reset the pref on major updates
(2.0 -> 3.0, and maybe 3.0 -> 3.1?)
Justin
Zack Weinberg
> I think the point you're trying to make is that it
> may be unexpected to have a preference reset to the default value on
> the upgrade of the browser.
Yes, although I would use stronger terms. It's not just that this is
unexpected; resetting preferences to the default value on upgrade is an
act of disrespect for the user and their choices.
> An alternative proposal (made by Shaver and others around the time
> this was becoming an issue for Firefox 3 ship) was to have a
> per-version pref.
This would have been better if it had been done at the time
(although, yes, aesthetically unpleasant) but now we're stuck with the
single boolean, eh?
> > but to make the consequences of the action clear at the time the
> > action is taken. I like Robert's suggestion of exposing the
> > compatibility
>
> We could easily do so by making this a user-facing pref in the
> Preferences pane. I don't think that's ever been the intent for this
> issue, and it feels to me that we're solving this on the wrong end at
> that point
Yeah. Making the existing boolean an exposed pref doesn't help
anything.
> > override in the extension manager UI on a per-extension basis. That
> > then gives us the opportunity to educate the user, and additional
>
> I don't see how per-extension makes it easier to educate the user.
> How will this solve the problem of the user realizing that setting
> the value at one time means potential instability when they next
> upgrade their browser, as well as potential instability at the time
> of the choice?
Well, think about the life cycle of extensions. The odds are that in
between two major upgrades to Firefox, all of the user's extensions
will also be upgraded, and that allows us to reset the (now
per-extension) pref without disrespecting the user, because conditions
have changed. (It would be polite to mention this when the upgrade
happens.) Furthermore, if we have the per-extension pref, we can use
that to highlight them in a list of extensions that might be causing
trouble, post-crash.
If an extension is force-activated after a major upgrade of the browser,
and when another major upgrade comes around, it has not been
disabled due to causing crashes nor has it been upgraded itself, then
it should remain active after the second major upgrade. Odds are it'll
be just fine. (If it starts causing crashes after the second major
upgrade, we have an opportunity to disable it then.)
I might even go farther, and say the *default* should be to leave
allegedly incompatible extensions active, but mark them as trouble
candidates for the post-crash dialogue.
> > information that can be used to do smart things if the browser
> > does crash. But we shouldn't go resetting the per-extension pref,
> > either, unless the extension itself is upgraded and changes its
> > stated support range.
(addressing your responses to this in the opposite order)
> I don't understand the second point; if the extension itself is rated
> as compatible, then there will be no interruption to the user's
> experience. The add-on will continue to work with or without the
> compatibility check override.
What I was trying to get at was, (assuming we have per-extension
compatibility override) if an extension has been force-activated, and
then a newer version of that extension comes out that *does* claim
support for the current browser version, then it'd be okay to
deactivate the compatibility override for that extension. With
notification, of course. (Just mention it in the upgrade screen.)
> Having proper blame for crashes isn't, IMO, the primary goal. The
> primary goal is to reduce the number of crashes and to ensure that
> those who are at risk of add-on instability are at that risk
> voluntarily.
I don't think we *can* ensure that risk of add-on instability is
voluntary, because that's not how end users are thinking about it. End
users are thinking "argh, I need my (firebug, adblock, greasemonkey,
&c.), what is the easiest possible way to get it working again?" And
then, later, if and when it crashes, they think "argh, this browser is
so unstable". They aren't going to associate the two events without
prompting. The crash recovery dialogue has the opportunity to do that
prompting; the extensions manager can also do it, but it's going to be
less effective. A hidden pref has no such opportunity, because it's
just a magic string.
(I'd support a drive to add one-or-two-sentence explanations to
every hidden pref, visible when the pref is selected in about:config,
but that's a separate project, and I don't think it'd help much with
this anyway.)
As for crashes, I gotta ask what your motivation for taking
sledgehammer approaches to reducing the number of crashes is. In my
happy little ideal world, we reduce crashes by fixing bugs and by
making the browser core more robust in the face of misbehaving
extensions. :-) I've seen it said that misbehaving extensions are
flooding the crash report server with useless reports - I'd argue that
if that's the major motivation here, the cure is to merge duplicates on
the server, and perhaps also use the extension blacklist more
aggressively to weed out known problem cases (it wins over the
compatibility check override, right?)
> > John Barton's suggestion of distinguishing extensions with binary
> > components from pure JS extensions also makes sense to me; we could,
> > at least, use it to tailor the strength of the warnings (change
> > "might cause instability" to "is likely to cause instability" for
> > instance).
>
> Do we know that's true? I think we'd rather build a more solid way of
> determining this, perhaps by being able to discern which add-ons are
> employing use of FUEL or other guaranteed APIs.
*shrug* I find his claim plausible, but I don't have data either way,
and I don't think it's the most important thing to worry about here.
> There's a lot we *could* do here, but in the interest of getting
> rolling on something which we know we *should* do, I'm going to say
> that Dave's proposal is a solid first step which can easily be
> extended and evolved to include all of these much better steps.
Well, I disagree with Dave's proposal, so naturally enough I don't
think it's a good first step either; rather a distraction from a
proper fix (and one which will make the user experience worse, not
better, meantime).
> > I think it's very
> > important not to piss off the people who *do* think about these
> > things; those people are in some sense our core constituency.
>
> This is a common refrain, but not one that I think is entirely valid.
> As long as we inform them why this is happening, and only do it at
> major version bumps, I think they'll understand that the value to
> end-users is stronger.
Possibly I am overgeneralizing from the people in this category that I
know personally, but I really don't think they will agree with that.
They're going to take the attitude that this is yet another case where
the browser is nannying them. (By way of comparison, they also hate
needing to click through - five screens, is it? - to get at an https:
url that serves a certificate that hasn't been signed by one of the
official CAs. They use phrases like "protection racket" and
"security theater.")
zw
Robert Kaiser
> I don't see how per-extension makes it easier to educate the user. How
> will this solve the problem of the user realizing that setting the value
> at one time means potential instability when they next upgrade their
> browser, as well as potential instability at the time of the choice?
We can educate the user at the point where he activates the
per-extension override and not make him do it via about:config where he
gets no warning or info what it means.
The biggest pro, for the per-extension variant is that from what I've
read here, the biggest problem we seem to have is people not turning it
off when they don't need it any more and/or often installing other than
the originally intended add-on that wouldn't be compatible because the
check is off and those then make their builds unstable.
If they can and need to go through an exception dialog with big warnings
every time they want to install and incompatible add-on and really use
it, similar to how we handle invalid certs, they can't inadvertently
install an incompatible add-on just because they have set the "I want to
be insane" switch through an interface (about:config) that didn't even
tell them it means "I want to be insane".
Robert Kaiser
Robert Strong
> Mike Beltzner wrote:
>
>> I don't see how per-extension makes it easier to educate the user. How
>> will this solve the problem of the user realizing that setting the value
>> at one time means potential instability when they next upgrade their
>> browser, as well as potential instability at the time of the choice?
>>
>
> We can educate the user at the point where he activates the
> per-extension override and not make him do it via about:config where he
> gets no warning or info what it means.
>
> The biggest pro, for the per-extension variant is that from what I've
> read here, the biggest problem we seem to have is people not turning it
> off when they don't need it any more and/or often installing other than
> the originally intended add-on that wouldn't be compatible because the
> check is off and those then make their builds unstable.
>
We could turn it off as well when all enabled add-ons are or become compatible but that would annoy a subset of people that don't think the app should change a user's choice regarding a hidden pref.
> If they can and need to go through an exception dialog with big warnings
> every time they want to install and incompatible add-on and really use
> it, similar to how we handle invalid certs, they can't inadvertently
> install an incompatible add-on just because they have set the "I want to
> be insane" switch through an interface (about:config) that didn't even
> tell them it means "I want to be insane".
We already warn the user when changing prefs and we also have a warning in the Add-ons mgr about compatibility checking being off though that could (probably should) be a much more strong warning.
I believe that if we have a significant problem with popular add-ons that haven't been updated then it would be better to address that separately from this specific issue. I also believe that more ui and backend logic to mark / reset individual extensions as compatible is not the answer for this specific problem... doing the right thing (whatever that turns out to be) for the majority of the users is the better course and those people using nightly builds, upgrading early, etc. can use the existing pref (which would get reset with the current proposal - perhaps just change its name for each release), extensions such as nightly tester tools, mr. tech's local install, etc.
Robert
Ben Hearsum
> I would like to suggest that we move to resetting
> extensions.checkCompatibility whenever a user installs a new version of
> Firefox, by which I mean an update that changes the version number, this
> would not affect mere nightly updates (except where they move from
> 3.1a1pre to 3.1a2pre for example).
>
I would suggest that doing resetting on a non-minor version number would
be more appropriate (eg, 3.0.1 -> 3.0.2 would _not_ reset, but 3.0 ->
3.1 would).
I'm not a developer, but it seems that if someone has unsupported
extensions enabled for whatever reason, a point release would not make
them change their mind and only serve to annoy. Furthermore, I think
it's much more understandable to have this reset on a more major update,
where APIs and other bustage inducing things may change.
Mike Beltzner
Dave proposed in the first place.
cheers,
mike
Ted Mielczarek
> As for crashes, I gotta ask what your motivation for taking
> sledgehammer approaches to reducing the number of crashes is. In my
> happy little ideal world, we reduce crashes by fixing bugs and by
> making the browser core more robust in the face of misbehaving
> extensions. :-) I've seen it said that misbehaving extensions are
> flooding the crash report server with useless reports - I'd argue that
> if that's the major motivation here, the cure is to merge duplicates on
> the server, and perhaps also use the extension blacklist more
> aggressively to weed out known problem cases (it wins over the
> compatibility check override, right?)
When we talk about the number of crashes, remember that we're not just
thinking about the server side of things. Every crash we record means
*a user experienced a crash*. That sucks for our users. We had quite a
few crashes in the topcrash list during our 3.0 beta cycle from people
explicitly overriding compatibility checks. A lot of the comments
suggested that they had no idea the crash and the pref were related..
This sucks, it means a lot of our users experienced crashes and had no
idea why, which makes them think we're shipping a bad browser. While I
think we should also find ways to inform users about the cause of
their crashes, making it so they can't crash themselves in the first
place would be great. I actually filed bug 422939 a while ago on
ignoring this pref for extensions with binary components, since that's
where all the crashes (that I've seen) happen.
-Ted
John J Barton
> On Jul 20, 7:11 pm, Zack Weinberg <zweinb...@mozilla.com> wrote:
>> As for crashes, I gotta ask what your motivation for taking
>> sledgehammer approaches to reducing the number of crashes is. In my
>> happy little ideal world, we reduce crashes by fixing bugs and by
>> making the browser core more robust in the face of misbehaving
>> extensions. :-) I've seen it said that misbehaving extensions are
>> flooding the crash report server with useless reports - I'd argue that
>> if that's the major motivation here, the cure is to merge duplicates on
>> the server, and perhaps also use the extension blacklist more
>> aggressively to weed out known problem cases (it wins over the
>> compatibility check override, right?)
>
> When we talk about the number of crashes, remember that we're not just
> thinking about the server side of things. Every crash we record means
> *a user experienced a crash*. That sucks for our users. We had quite a
> few crashes in the topcrash list during our 3.0 beta cycle from people
> explicitly overriding compatibility checks. A lot of the comments
> suggested that they had no idea the crash and the pref were related..
This is a user-reported problem. It makes the case for *informing*
users that a previous operation they performed could have allowed the
crash they just experienced. It does not make the case for *changing* a
previous user operation just in case it might cause a crash later.
Why can't the crash reporter say:
"You have set extensions.compatibilityCheck to false; some incompatible
extensions can crash Firefox". (With a link).
Jonas Sicking
> John J Barton <johnj...@johnjbarton.com> wrote:
>> chris hofmann wrote:
>> ...
>>> If an extension developer thinks thier extension is ready for a lot
>>> of use during a beta test period they should bump the version
>>> number, get the old extension (or the latest update) out in use.
>> The basic problem is that the only practical way many extension
>> developers have to find out if there are compatibility problems is
>> from user reports.
>
> the "Firefox appears to have crashed, do you want to try to recover
> your tabs?" dialog box. How about detecting when a crash is likely to
> have been caused by an extension, and offering to guide the user
> through a series of tests, disabling extensions one at a time until the
> offending one is identified, and then (a) blacklists that extension
> until upgraded, (b) auto-files a bug report?
This sounds like a great idea to me, with some simplification.
It'd would be really really hard to detect when the cause of the crash
is even possibly due to a specific extension. But what we could do is to
detect that compat checking is turned off and there are incompatible
extensions installed. We could then in the dialog list which extensions
aren't compatible and automatically disable them, or switch the compat
checking flag, or some such.
/ Jonas
chris hofmann
would this content shown to the user that:
-connects the crash data we have on the server to extension related
problems,
-offers guidance on which extensions are compatibile and which are not,
-leads the user though diagnostics
-provides instruction on how to remedy problems
be web based?
that won't work for the number of "crash on start-up" based extension
problems since the browser never gets to a state where it can display
content. In that case we would need to auto-disable all extensions
then try a restart and that brings us back around to the solution
suggested at the start of the thread.
trying to get all this logic and data in a client based solution also
seems problematic in trying to keep it up-to-date with the latest known
information.
the sequence we saw in fx3 where:
-older browser version installed
-user has added some extensions
-(compatibility checks turned off at some point)
-user wants to join new browser beta - downloads and installs
--browser starts crashing
-we collect enough data over a few weeks to understand which extension
are problematic and what actions are needed, including several which
will involve turning off the version checking override...
-information gets to a state where we can start providing to users
doesn't really seem to lend itself to effective use for the millions
that we saw downloading some of the fx3 betas within days of the beta
release date.
The sequence of
older browser version installed
-user has added some extensions
-(compatibility checks turned off at some point)
user wants to join new beta program
unset the compatibility check override (user does this, or we do it for
them)
install the beta
run for a while, then start incrementally adding extensions until
something breaks
is really what we are trying to re-enforce during development periods.
-chofmann
Dave Townsend
Yes my original thought was to do it for every version change. I think
not resetting for minor updates is potentially a good thing, though that
introduces complications (which part of the version corresponds to
"minor" changes).
Mike Shaver
> Yes my original thought was to do it for every version change. I think
> not resetting for minor updates is potentially a good thing, though that
> introduces complications (which part of the version corresponds to
> "minor" changes).
Just rename the pref on every major version. Then you don't "reset"
anything if people bring up an older browser, etc. Easy, clear,
basically foolproof.
I think the global pref is vastly more useful during testing than
during release cycles, so we may want to bump on trunk now and then
bump again at RC/release time. Similarly with the malware prefs,
which I suspect a bunch of people turned off when it was buggy in
earlier builds, and then just left turned off passively. I think it's
like putting a "snooze button" on a smoke detector, so you don't just
turn it completely off when you burn something and forget to switch it
back on afterwards.
I proposed that we put some magic word in the prefs so that we don't
just get some "helpful post" instructing people to pre-set their
compat_3_1 compat_3_2 compat_4 prefs and putting users back where we
started.
(I did like the earlier description of using self-signed certs as
security theatre; I haven't head that explanation of the delusion
behind their use, but I'll be using it more in the future!)
Mike
Mike Beltzner
>> Actually, my read of the original post was that the pref would be
>> reset
>> on any version change (3.1a1 -> 3.1a2 being the example). I'd assume
>> it's just a small refinement to only reset the pref on major updates
>> (2.0 -> 3.0, and maybe 3.0 -> 3.1?)
>
> Yes my original thought was to do it for every version change. I think
> not resetting for minor updates is potentially a good thing, though
> that
> introduces complications (which part of the version corresponds to
> "minor" changes).
For now I think we can guarantee you that minor versions will only
affect the third or fourth digits of the Firefox version, first and
second will always imply major. Good enough?
cheers,
mike
Mike Shaver
> For now I think we can guarantee you that minor versions will only
> affect the third or fourth digits of the Firefox version, first and
> second will always imply major. Good enough?
Let's not impose version semantics on toolkit code that are going to
hurt us or other toolkit consumers down the line. My original
proposal (would that I'd pushed on it harder at the time(s), I guess)
was for simply renaming the pref in question at bump time. The app
can tell toolkit what its override pref is, and then toolkit's EM just
checks that.
Mike
Mike Beltzner
Toolkit code can be changed down the line, as well. I'm more
interested in building a system that doesn't break for minor updates,
which happen every few weeks. Am I missing something about the version
bump system that solves that issue?
cheers,
mike
Mike Shaver
> Toolkit code can be changed down the line, as well. I'm more interested in
> building a system that doesn't break for minor updates, which happen every
> few weeks. Am I missing something about the version bump system that solves
> that issue?
Yeah, we just wouldn't change the name of the pref until we wanted it
to invalidate. Check in a change on the trunk now, check in another
change when we hit RC, etc. Don't check in a pref-name change on the
minor-update branch, and the pref doesn't change.
Mike
Mike Beltzner
Hot. That works for me.
cheers,
mike
Zack Weinberg
> (I did like the earlier description of using self-signed certs as
> security theatre; I haven't head that explanation of the delusion
> behind their use, but I'll be using it more in the future!)
You misunderstood my rather telegraphic quote. The people I was
referring to think *OUR CERTIFICATE UI* is security theatre; it's (in
their opinion) designed to scare people into trusting only a certain
set of sites, which is not necessarily the set of sites that are
actually *trustworthy*, just the set of sites that are willing to fork
over the money for a certificate signed by one of the CAs that we
happen to have included in the browser's default set.
There is also, I think, quite a lot of resentment of bad business
practices by the CAs in there - I have seen several people use the
phrase "the Verisign protection racket" - I don't know enough to say
whether that's based on current experience or left over from the first
boom or what, but anyway it spills over on the browser, which is a
convenient target.
(I should mention that one of the loudest complainers I saw was a
person who was using a CA that we *didn't* include, for no reason
apparent to him.)
zw
Justin Dolske
> Just rename the pref on every major version. Then you don't "reset"
> anything if people bring up an older browser, etc. Easy, clear,
> basically foolproof.
Well, foolproof until we forget to rename the pref. Although I suppose
you could just compute it at runtime.
Justin
Zack Weinberg
> would this content shown to the user that:
>
> -connects the crash data we have on the server to extension related
> problems,
> -offers guidance on which extensions are compatibile and which are
> not, -leads the user though diagnostics
> -provides instruction on how to remedy problems
>
> be web based?
>
> that won't work for the number of "crash on start-up" based extension
> problems since the browser never gets to a state where it can display
> content.
Well, for one thing, your suggestion is a lot more baroque than
anything I had in mind; I just imagined a dialog box with canned text
saying "crashes may be caused by extensions - would you like to try
repeating what you just did with extensions disabled to see if that was
the cause of the problem" and maybe a "yeah, it works now" button in
the toolbar.
But if we *want* to make it more sophisticated than that, there are
ways around the problem you state. For instance, we could isolate the
post-crash interaction in a separate xulrunner app, running in a
separate process and watchdogging the browser as we try to bring it
back up. That app could then, if we found it useful, pull down
information from the net.
We can't count on net access anyway - maybe the problem only happens in
offline mode.
> In that case we would need to auto-disable all extensions
> then try a restart and that brings us back around to the solution
> suggested at the start of the thread.
Disabling extensions as a response to a crash is not at all the same
thing as preemptively disabling extensions because the browser has been
upgraded and there *might* be a crash in the future.
> The sequence of
>
> older browser version installed
> -user has added some extensions
> -(compatibility checks turned off at some point)
>
> user wants to join new beta program
> unset the compatibility check override (user does this, or we do it
> for them)
> install the beta
> run for a while, then start incrementally adding extensions until
> something breaks
>
> is really what we are trying to re-enforce during development periods.
Except for fun stuff like PMOG, extensions aren't used like that. I
can very easily see people refusing to upgrade to the beta - or,
perhaps, installing the beta and then immediately deinstalling it when
they saw what had happened - rather than do without Adblock, or
Greasemonkey (or perhaps one specific Greasemonkey script that the beta
breaks and they consider essential), or their password generator. This
is especially true for people who cared enough to find out how to
override the version check. And print media ran stories on how to
override the version check, which should tell you that lots of people
really do care that much.
(I *know* people who refused to use FF.3beta because there was no
Firebug for it, but that's a bad example, since old Firebug genuinely
didn't work with the betas.)
If we really want people to test the betas like that, we need to be
making it easier to keep using the old version but experiment with the
new one at the same time. Not just install in parallel; run in
parallel, and with profile isolation. (See for instance bug 443078.)
As long as we don't do that, though, I think we're going to get *less*
testing of the betas if we start ignoring the version-check override.
zw
Mike Shaver
No, the whole point of this subthread is that computing it at runtime
is fragile. I don't think it's unreasonable to add a "rename compat
pref" item to the release checklist, along with the branding switch-on
and so forth.
Mike