Closed Bug 310698 Opened 19 years ago Closed 14 years ago

Update needs to allow for cancel update. Today several extensions were disabled after the fact.

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: thethirddoorontheleft, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051001 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051001 Firefox/1.4.1

The check for updates is a great feature but it needs to allow for cancel
conditions when it seriously changes the ladscape of the current install.
There are to many dependecies on extensions to simple go forward and disable
them because it could be weeks or months before they are fixed.


Reproducible: Sometimes

Steps to Reproduce:
1. It not known when it will occurs.
2.
3.

Actual Results:  
Two extensions were disabled and they are not going to be fixed anytime soon.

Expected Results:  
Final update commit or canel button, please.
Hmm... the auto-update system is supposed to prompt you when extensions may be
broken by an update so that you can choose not to proceed with the update.

I wonder if the data from the update server is not properly reporting the update
as a major update.
(In reply to comment #1)
> Hmm... the auto-update system is supposed to prompt you when extensions may be
> broken by an update so that you can choose not to proceed with the update.
> 
> I wonder if the data from the update server is not properly reporting the update
> as a major update.

The update server for the nightly channel has no way of telling that an update
is either minor or major.  Darin, if there's a straightforward way for AUS to
infer that certain version bumps are major and others are minor, we can talk
about integrating that feature into nightly channel updates.

Please don't infer what will happen with an update from the beta1 release to the
beta2 release by looking at what happens with updates along the nightly channel.
 Mozilla developers will be setting the beta channel policy directly and the
updates will be put into that channel by hand.
(In reply to comment #1)
> Hmm... the auto-update system is supposed to prompt you when extensions may be
> broken by an update so that you can choose not to proceed with the update.
> 
> I wonder if the data from the update server is not properly reporting the update
> as a major update.

I tried to reproduce it by re-installing the 30th build as there was an extra
days copy in the i686 lastest on my the mirror. It did come up in help as the 30th.

But, it seems to be more complex than a re-run.
The instal must have updated to the current as well as showing the extension
incompat screen. It did not have a canel update as I think that was already done
but had (look for new extension updates option).

The strange thing was that it show only the older disabled extentions and not
the ones disabled today during install.
But after I closed the installing run in term and re-launched from my
applauncher aall the extensions were listed and the ones that had been disabled
from the 10/01/05 update, but they did NOT say disabled, just gray out.

So several differnet conditions occuring depending on the path of update is
approached. ??

It's all your now. :)
thanks

Darwin
Well, I spoke too soon. It more interesting than I thoht.

  The updates were not applied as I checked for updates to see what it would say.

1. There was an update and it applied it.
Then showed the old disabled list - check for new verions option.
2. Click to restart and it did.
3. Unable to apply partical update must do a complete install.
It did (now I can't remeber if it restarted again first or not) but
4. The complete list of incompat extensions can up ... continue
5. The extensions show disabled )old and todays)

Darwin
Group: security
> Please don't infer what will happen with an update from the beta1 release to the
> beta2 release by looking at what happens with updates along the nightly channel.

Chase: OK, I was just concerned because I didn't know if the problem was that
AUS had not been configured for the change or if Firefox did not deal with the
change properly.  If the problem is with Firefox, then we need to act quickly to
resolve it.  If it can be entirely resolved on the AUS end, then we have nothing
to worry about :-)


(In reply to comment #5)
> If the problem is with Firefox, then we need to act quickly to resolve it.
> If it can be entirely resolved on the AUS end, then we have nothing
> to worry about :-)

Until we've actually done the beta1->beta2 upgrade we don't *know* whether or
not we have anything to worry about :-(

Regardless of that, the change requested in this bug is worth considering. There
are times when it's not convenient to upgrade, and having a choice of "now or
next start" means I have to keep a window open and hope I don't crash. Most of
the time I end up wishing "Later" meant "Ask me later" rather than "just do it".

Note to Darwin: folks on IRC or mozillazine forums can get your extensions
running again if you need help (either edit the install.rdf's or change the
internal version number pref)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Update needs to allow for canel update. Today several extensions were disabled after the fact. → Update needs to allow for cancel update. Today several extensions were disabled after the fact.
(In reply to comment #6)
> are times when it's not convenient to upgrade, and having a choice of "now or
> next start" means I have to keep a window open and hope I don't crash. Most of

So, there *are* ways of not upgrading. In Tools > Options > Advanced > Update
there is an option for what to do when an application update is found. The
default is to install immediately, but to ask in cases where extensions will be
disabled, which is what Darin was talking about in comment 1. These are the
default settings (with corresponding prefs):

| When updates for Firefox are found,                        |
|    ( ) Ask me what I want to do                            | (app.update.auto)
|    (o) Automatically download and install the update       | (app.update.auto)
|      [x] Warn me if this will disable extensions or themes | (app.update.mode)

If a user doesn't want to be automatically updated, the pref can be easily
flipped. However, the default case should be that updates which we push to the
release channel will be automatically applied, and users will be given the
chance to back out only if it will disable extensions or themes. With this first
dialog that asks the user what they want to do, the "Later" acts as you'd
expect, just re-running the check later.

I'm not sure that we want to add an "abandon" button for when the update has
already been downloaded.
the current order that things happen is a bit backward.  i have fx set to ask me if i want to do the update.  i just crashed 1.5.0.1.  upon restart:
1) firefox 1.5.0.1 noticed an available update and asked me if i wanted it
2) when i said yes, fx downloaded the update
3) fx applied the update
4) fx checked for inompatible extensions and warned me that there was one

shouldn't the incompatible extension check happen before the download?
There shouldn't be any extension incompatibility between 1.5.0.1 and 1.5.0.2, unless the extension author inappropirately set the maxVer to 1.5.0.1 instead of 1.5.0.*

But yes, you're quite right that these settings should do the extension compatability check BEFORE downloading the update so that the app can honour the setting of "Warn me if this will disable extensions or themes".
(In reply to comment #7)
> So, there *are* ways of not upgrading.

Yes, but it involves *proactively* setting FF not to auto-upgrade.  Please consider adding some option in the *default* auto-update dialog to postpone the auto-update, even if it has to be strongly deprecated to make sure 99.99% of normal users update anyway (and yes, they would, I don't think people would just not update 'for no particular reason', if it were suggested by the app they almost certainly would).  As for why I'd like this, I've gone into much more detail in my summery of bug #335798 so please read that.
Darin or Rob, can we get some clarification here: if a user is running version A with extensions that have a maxVer of A, and an update to B is available, under the default settings (auto-update but warn if it will make ext/themes not work) do they get the option to not install the update?

Also: reporter should see bug 324121 comment 10 which is very much on the point of this issue.
Mike, I don't know the app update code which is where this happens but either Darin or Ben should... I believe that the behavior is suppose to be as you described though.
Unfortunately, I'm less familiar with this part of AU.  It's something that I would need to investigate.  Ben G and/or Ben T may have some ideas about this one though.
*** Bug 347827 has been marked as a duplicate of this bug. ***
(In reply to comment #14)
> *** Bug 347827 has been marked as a duplicate of this bug. ***
> 
It is not exactly a duplicate. This bug report (a) requests an option to turn off all updates (until some extension has been updated) and (b) asks for some automated detection of a clash where the updating option has been set to 'automatic'.

In 347827 it has been assumed that 'ask what I want to do' has been selected, so that whenever there is a new update the user is offered it. The complaint is that there are only two buttons: 'update now' and 'update later'. If the latter is selected then the availability of the update is reported every few days thereafter. There should be 'Not this update' button so that that particular update will no longer be offered, though future ones (which may have more desirable features are offered). Bug 347827 explains the motivation in more detail.
I think the 'not this update' button should be easier to provide, assuming every update has a unique ID (or date) associated with it.
Thanks
Product: Firefox → Toolkit
Regarding the problem as reported, As of Firefox 3.6 app update correctly checks and reports if add-ons will be disabled due to being incompatible with an update. So, resolving -> wfm.

Regarding adding a cancel option there is bug 300922 and bug 336267.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.