575255 - [ACR Extension] ACR makes preferences menu enabled for every add-on even if they don't have preferences

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Compatibility Tools, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a6pre) Gecko/20100625 Minefield/3.7a6pre

If an add-on doesn't provide preferences the Preferences menu item has to be disabled. As example you can take ACR (see the link above). Otherwise users will get the impression that the preferences can't be opened. The state of the buttons is correct.

Comment 1

[Dave Townsend [:mossop]]

This appears to be a bug with the ACR as it works fine without it installed.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The problem we hit here is that we wrongly parse the install.rdf. The ACR extension has a multi-line comment and that one is not recognized by our parser:

<!-- <em:optionsURL>chrome://acr/content/ui/options.xul</em:optionsURL>
<em:iconURL>chrome://acr/skin/images/star32.png</em:iconURL> -->

I'm able to reproduce it with any add-on and it was working in Firefox 3.6.

Comment 3

[Dave Townsend [:mossop]]

(In reply to comment #2)
> The problem we hit here is that we wrongly parse the install.rdf. The ACR
> extension has a multi-line comment and that one is not recognized by our
> parser:
> 
> <!-- <em:optionsURL>chrome://acr/content/ui/options.xul</em:optionsURL>
> <em:iconURL>chrome://acr/skin/images/star32.png</em:iconURL> -->

I don't see any signs that we are failing to parse this install.rdf correctly. All of the data goes into the database as expected and it would be very unlikely that bad data in the install.rdf for a single add-on would affect every other add-on like this. To verify I removed the entire comment block and reinstalled it and still with ACR enabled every single add-on in the list shows an enabled Preferences menu, with it disabled only the add-ons with settings windows shows Preferences enabled.

> I'm able to reproduce it with any add-on and it was working in Firefox 3.6.

What are you able to reproduce exactly?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Sorry, you are right. All extensions I had installed had a preference dialog. So I wasn't seeing that all add-ons get the preference context menu item enabled. Now with the DOM inspector installed too, I can also see it.

Moving over again to the ACR extension.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #3)
> > I'm able to reproduce it with any add-on and it was working in Firefox 3.6.
> 
> What are you able to reproduce exactly?

With Firefox 3.6 the DOM inspector doesn't have the preference menu item enabled. So it looks like a bad interaction between ACR and the new API.

Comment 6

[Brian King [:kinger]]

-> for a 0.5.1 release.

Comment 8

[Brian King [:kinger]]

Problem code is the overriding of gViewController.updateCommands in extensionsOverlayController.js:

        ACR.Controller.ExtensionsOverlay._updateCommandsStack = gViewController.updateCommands;
        gViewController.updateCommands = function()
        {
            ACR.Controller.ExtensionsOverlay._updateCommandsStack();
            ACR.Controller.ExtensionsOverlay._invalidateCompatibilityButtons();
        }

The original commands are not being updated ... investigating more...

Comment 9

[Brian King [:kinger]]

Fixed, r72373. Instead of overriding updateCommands, I switched to adding an event listener for "ViewChanged". Seems to be just what we need.

Comment 11

[[not reading bugmail]]

Was this fixed for a specific version of ACR?

Comment 12

[Brian King [:kinger]]

(In reply to comment #11)
> Was this fixed for a specific version of ACR?

Watch for 0.6, which should be released very soon.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Looks good with 0.6. Marking as verified fixed.