264750 - Updating disabled extensions re-enables them

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Mark Janssen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040924 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040924 Firefox/0.10.1

When I updated a disabled extension (disabled by me and not automatically
because of incompatibility), restarting firefox re-enabled the extension again.

Reproducible: Always
Steps to Reproduce:
1. Disable not-up-to-date an extension
2. Update the extensions
3. Restart Firefox

Actual Results:  
The extension was enabled again.

Expected Results:  
Leave the extension disabled.

Comment 1

[Nickolay_Ponomarev]

related: bug 260754

You did *NOT* restart between disabling and updating the extension, right?

Comment 2

[Mark Janssen]

AFAIK It doesn't matter if you restart or not.

Comment 3

[Tracy Walker [:tracy]]

confirmed with windows build 2004-10-18-07-0.9

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Can someone confirm this with current trunk/1.1a2 builds?

Comment 5

[James Ross]

Confirmed on "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8b3)
Gecko/20050711 Firefox/1.0+".

There's two related issues here, I should point out.

Firstly, the option to check for updates in Tools > Options > Advanced > Update
will check disabled extensions for updates (arguable both ways whether this
should happen) and, secondly, when it does find an update the extension is
re-enabled post-update (which is what this bug is specifically about).

Comment 6

[Robert Strong (they/them - no direct email)]

Attachment: patch in progress

Comment 7

[Robert Strong (they/them - no direct email)]

Attachment: patch in progress

This retains the user disabled state when an incompatibility check makes an
installed item compatible. Now to add retention of the user disabled state when
an item is upgraded.

Comment 8

[Robert Strong (they/them - no direct email)]

Attachment: patch

Comment 9

[Benjamin Smedberg]

Comment on attachment 189525 [details] [diff] [review]
patch

Will "appDisabled" be used for the extension-dependency auto-disablement also,
or will you need a third property for that?

Comment 10

[Robert Strong (they/them - no direct email)]

Comment on attachment 189525 [details] [diff] [review]
patch

It will be used for extension dependencies as well.

Comment 11

[Robert Strong (they/them - no direct email)]

I'm going to hold off on this until after bug 297312 and bug 296566 are checked in.

Comment 12

[Robert Strong (they/them - no direct email)]

Attachment: patch (Checked in)

Benjamin - this has a couple of minor tweaks to the old patch and also adds
feedback to the EM ui during update. It also removes getUpdateableItemList
since I moved the checks into checkForUpdates due to the ui not providing
feedback of what is going on to the user. If you prefer that I separate the ui
updating code into a new patch I will but I won't be able to for a few hours.

Comment 13

[Benjamin Smedberg]

Comment on attachment 190458 [details] [diff] [review]
patch (Checked in)

beautiful

Comment 14

[Ian Neal]

Comment on attachment 190458 [details] [diff] [review]
patch (Checked in)

Checking in
mozapps/extensions/public/nsIExtensionManager.idl;
new revision: 1.39; previous revision: 1.38
mozapps/extensions/src/nsExtensionManager.js.in;
new revision: 1.134; previous revision: 1.133
mozapps/extensions/content/update.js;
new revision: 1.15; previous revision: 1.14
locales/en-US/chrome/mozapps/extensions/extensions.properties;
new revision: 1.17; previous revision: 1.16
done

Comment 15

[Robert Strong (they/them - no direct email)]

Fixed on trunk.

Comment 16

[Robert Strong (they/them - no direct email)]

*** Bug 299496 has been marked as a duplicate of this bug. ***