704165 - Undo button has no functionality when switching strictCompatibility pref after upgrade

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (Windows NT 5.1; rv:11.0a1) Gecko/20111120 Firefox/11.0a1

STR:
1. Start any Firefox version<11
2. Install an add-on which is incompatible with Firefox 11 (e.g. Greasemonkey 0.9.13)
3. Upgrade to Firefox 11.
4. Disable the strictCompatibility pref (extensions.strictCompatibility->true)
5. In add-on Manager select "undo" button for the add-on installed at step 2.

Actual result: Selecting "Undo" doesn't trigger any action.

Expected result: The button should trigger an action or be missing when switching the pref.

Comment 1

[Dave Townsend [:mossop]]

I wouldn't even expect there to be an undo button there. What does the text by it say?

Comment 2

[Virgil Dicu [:virgil] [QA]]

Attachment: screenshot with Add-on Manager after switching pref for incompatible add-ons

Add-on X will be disabled after you restart Nightly. 
Related to bug 702920. That refers to user disabled add-ons.

Comment 3

[Dave Townsend [:mossop]]

Yeah the undo button looks like a mistake there

Comment 4

[Blair McBride [:Unfocused] (UNAVAILABLE)]

I believe this has always been a bug, not a regression from default-to-compatible - it just has an easier way to hit it now. The UI code assumes that a pending enable/disable was user-initiated, because the API doesn't specify the reason.

Easiest fix may be to add two additional pending states: PENDING_APP_ENABLE and PENDING_APP_DISABLE

Comment 5

[Dave Townsend [:mossop]]

(In reply to Blair McBride (:Unfocused) from comment #4)
> I believe this has always been a bug, not a regression from
> default-to-compatible - it just has an easier way to hit it now. The UI code
> assumes that a pending enable/disable was user-initiated, because the API
> doesn't specify the reason.

Ah you may be right yeah

> Easiest fix may be to add two additional pending states: PENDING_APP_ENABLE
> and PENDING_APP_DISABLE

Or just not show if userDisabled == isActive?

Comment 6

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Dave Townsend (:Mossop) from comment #5)
> Or just not show if userDisabled == isActive?

Oh, yes - that's much better :)

Comment 7

[realgrouchy]

I don't fully understand the initial report, so this information may be redundant.

Summary: The screenshot in the first attachment doesn't have the "Compatibility checking is disabled" message that I have. Next to this message is an "Enable" link that marks "incompatible" add-ons to be disabled at next restart, and the "undo" buttons appear at this point, with no function. Details below...

In SeaMonkey 2.1.6, my add-on compatibility checking is apparently disabled (default?), though I have a number of extensions that work (which either got grandfathered in and/or I manually edited the install.rdf file) but are listed as "not compatible".

1. I marked the various "incompatible" add-ons as being compatible.
2. I clicked the "Enable" link next to the warning that compatibility checking is disabled.
3. Result: it marked my 'incompatible' add-ons (the ones I marked as compatible) that they would be disabled the next time I restart. (Expected result: my marking them compatible would have overridden the compatibility checker marking them to be disabled)
4. Clicking "undo" on these entries did nothing.

And just for reference...

5. After a restart, when I went to the add-ons page, the 'incompatible' add-ons were disabled (as it said it would), and my flags marking them as compatible were still active, and these add-ons were already marked that they would be enabled the next time I restart.
6. After restarting, the compatibility checking is disabled again (fine, whatever). 
7. This is the point at which I took the screenshot that I will attach.

I might just be misinterpreting the "compatibility checking is disabled" message and that it is working properly. My lay understanding is that it's confusing for it to say that checking is disabled, when it's obviously checking the compatibility (as evidenced by the 'incompatible' add-ons being marked). What I think the message means to say is that it isn't automatically *disabling* the add-ons that it thinks are incompatible. 

Either the wording of the message should be changed, or a "more info" link should be added to the "Compatibility checking is disabled" message that explains, for example, "Click 'Enable' to automatically disable incompatible add-ons".

Despite these semantics, I don't think the compatibility checker should disable add-ons that I've manually marked as being compatible, and even if it does, the undo buttons should work.

(Sorry if I rambled on there)

- RG>

Comment 8

[realgrouchy]

Attachment: Screenshot of SeaMonkey (modern theme) with "Compatibility Checking is disabled" message

As described in previous comment. Hope it's helpful.

Comment 9

[Dave Townsend [:mossop]]

(In reply to realgrouchy from comment #7)
> In SeaMonkey 2.1.6, my add-on compatibility checking is apparently disabled
> (default?), though I have a number of extensions that work (which either got
> grandfathered in and/or I manually edited the install.rdf file) but are
> listed as "not compatible".

That isn't the default in Firefox, I'm pretty sure it isn't the default in SeaMonkey either. Either you've set the preference in about:config or some add-on you have installed (Add-on Compatibility Reporter probably) has set this for you.

> 1. I marked the various "incompatible" add-ons as being compatible.
> 2. I clicked the "Enable" link next to the warning that compatibility
> checking is disabled.
> 3. Result: it marked my 'incompatible' add-ons (the ones I marked as
> compatible) that they would be disabled the next time I restart. (Expected
> result: my marking them compatible would have overridden the compatibility
> checker marking them to be disabled)
> 4. Clicking "undo" on these entries did nothing.

Yes that is what this bug is talking about fixing. 

> I might just be misinterpreting the "compatibility checking is disabled"
> message and that it is working properly. My lay understanding is that it's
> confusing for it to say that checking is disabled, when it's obviously
> checking the compatibility (as evidenced by the 'incompatible' add-ons being
> marked). What I think the message means to say is that it isn't
> automatically *disabling* the add-ons that it thinks are incompatible. 
> 
> Either the wording of the message should be changed, or a "more info" link
> should be added to the "Compatibility checking is disabled" message that
> explains, for example, "Click 'Enable' to automatically disable incompatible
> add-ons".

This is a different bug, you're welcome to file it if you like but I'm not sure it is worth us putting much effort into. Disabling compatibility checking has always been something we allowed mainly for nightly users and developers, I don't have a lot of interest in making it usable for regular users.

> Despite these semantics, I don't think the compatibility checker should
> disable add-ons that I've manually marked as being compatible, and even if
> it does, the undo buttons should work.

The marking as compatible thing is an Add-on Compatibility Reporter function, not part of Firefox.

Comment 10

[realgrouchy]

Thanks for the explanation.

Comment 11

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.