581482 - An add-on's entry in the Tools menu on trunk will not be visible after running older version of Firefox

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Aaron Train [:aaronmt]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100723 Minefield/4.0b3pre

Currently with the new add-ons manager, 

STR: 
1. Install a compatible add-on for trunk
2. Check that it has an entry in the Tools menu.
3. Close Minefield and open an older branch, i.e., Namoroka
4. Check that it has an entry in the Tools menu.
5. Close Namoroka and open Minefield.
6. Check that it has an entry in the Tools menu.

ER: Step 6: Should see the same addon in the Tools menu. Opening the add-ons manager confirms that it is enabled.

AR: Step 6: The add-on's entry in the Tools menu is not visible.

Comment 1

[Aaron Train [:aaronmt]]

Tested with http://bitbucket.org/jonallengriffin/grafxbot/downloads/grafxbot-0.1.13g.xpi

Comment 2

[Aaron Train [:aaronmt]]

A present workaround to resolve the issue in trunk is to disable/restart and enable/restart the browser.

Comment 3

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

Have you used that profile before in Namoroka or is it a new one created with Minefield?

Comment 4

[Aaron Train [:aaronmt]]

(In reply to comment #3)
> Have you used that profile before in Namoroka or is it a new one created with
> Minefield?

1. Clean profile created in Minefield duplicates this issue.
2. Installed addons: Grafx bot, DOM Inspector

Both entries are removed.

Comment 5

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

Both are not compatible with current versions on trunk or 4.0b2. I assume you have disabled checkCompatibility.

Comment 6

[Aaron Train [:aaronmt]]

(In reply to comment #5)
> Both are not compatible with current versions on trunk or 4.0b2. I assume you
> have disabled checkCompatibility.

Fresh profile, no preferences altered. I can duplicate this with Grafx bot strictly which is 4.0.*

Comment 7

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

Ok, Grafx Bot hasn't been reviewed yet. I can reproduce now. Will give additional information shortly.

Comment 8

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

Grafx bot is not compatible with Firefox 3.6.x. It only works on trunk. That's why it is disabled on 1.9.2. I can't see the issue with DOM inspector. Looks invalid to me.

Comment 9

[Aaron Train [:aaronmt]]

(In reply to comment #8)
> Grafx bot is not compatible with Firefox 3.6.x. It only works on trunk. That's
> why it is disabled on 1.9.2. I can't see the issue with DOM inspector. Looks
> invalid to me.

This is not the problem. The problem is *returning* back to Minefield and the entry is missing.

Comment 10

[Aaron Train [:aaronmt]]

Attachment: Tools menu

If it helps to understand, this is what I see when I return back to Minefield - a missing entry in the menu that was once there prior to opening a past version of Firefox. The add-on is enabled.

Comment 11

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

Ok, I missed the URL from comment 1 but I still can't reproduce the problem. The tools entry is always present. But extension logging shows the following output:

*** LOG addons.xpi: Skipping unavailable install location app-system-share
*** LOG addons.xpi: checkForChanges
*** ERROR addons.xpi: Error processing file changes: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: resource://gre/modules/XPIProvider.jsm :: anonymous :: line 777"  data: no]
*** LOG addons.xpi: No changes found

Comment 12

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

773 function copyRowProperties(aRow, aProperties, aTarget) {
774   if (!aTarget)
775     aTarget = {};
776   aProperties.forEach(function(aProp) {
777     aTarget[aProp] = aRow.getResultByName(aProp);
778   });
779   return aTarget;
780 }

Comment 13

[Dave Townsend [:mossop]]

The problem here is that when you run Minefield for the second time it doesn't see that any changes to extensions have occurred since the last time it was run, so it doesn't bother to update extensions.ini which Namoroka will have overwritten.

Comment 14

[Dave Townsend [:mossop]]

(In reply to comment #11)
> Ok, I missed the URL from comment 1 but I still can't reproduce the problem.
> The tools entry is always present. But extension logging shows the following
> output:
> 
> *** LOG addons.xpi: Skipping unavailable install location app-system-share
> *** LOG addons.xpi: checkForChanges
> *** ERROR addons.xpi: Error processing file changes: [Exception... "Illegal
> value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
> resource://gre/modules/XPIProvider.jsm :: anonymous :: line 777"  data: no]
> *** LOG addons.xpi: No changes found

I don't know what this is but it seems unrelated since you are seeing different problems. Might need a new bug.

Comment 15

[Dave Townsend [:mossop]]

Actually this is not quite so straightforward as I thought, my tests cannot reproduce it. The extensions.ini gets wiped whenever the platform detects an app change and then we rebuild so this isn't the problem I thought it was.

Comment 16

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

The mentioned error from above comes from assigning the following properties to the target array:

aProp: os
arop: abi
aProp: os
aProp: abi
aProp: os
aProp: abi
aProp: os
aProp: abi
aProp: os
aProp: abi

Is that definitely another bug? If yes, I can file it as a new bug.

Comment 17

[Dave Townsend [:mossop]]

(In reply to comment #16)
> Is that definitely another bug? If yes, I can file it as a new bug.

You're seeing different symptoms to this bug report so yes, file it as a new bug.

Comment 18

[Dave Townsend [:mossop]]

Can you re-test this with extensions.logging.enabled turned on. When you run Minefield in the last step run it from the command line and copy the logging that shows up here.

Comment 19

[Aaron Train [:aaronmt]]

Attachment: Log

Comment 20

[Dave Townsend [:mossop]]

(In reply to comment #17)
> (In reply to comment #16)
> > Is that definitely another bug? If yes, I can file it as a new bug.
> 
> You're seeing different symptoms to this bug report so yes, file it as a new
> bug.

Hmm, this might be the same bug after all, but I have no idea why you aren't seeing the same effects

Comment 21

[Aaron Train [:aaronmt]]

If it makes any difference, in my testing

Minefield: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100723 Minefield/4.0b3pre

64 - x86_64-apple-darwin10.2.0, whereas Namoroka is powerpc-apple-darwin9.2.0

Namoroka: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9pre) Gecko/20100723 Namoroka/3.6.9pre

Comment 22

[Dave Townsend [:mossop]]

Do either of you have any other extensions installed in the same profile?

Comment 23

[Aaron Train [:aaronmt]]

(In reply to comment #22)
> Do either of you have any other extensions installed in the same profile?

Not any other extensions installed on my behalf.

Comment 24

[Aaron Train [:aaronmt]]

Interestingly, I can not reproduce with this extension. Fresh profile, single extension installed

ftp://ftp.mozilla.org/pub/mozilla.org/labs/weave/development/1.4.x/weave-1.4.2b1-dev.xpi

Comment 25

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

I have to correct me, I was able to see the problem. But it's not consistent. As testing right now shows, the menu entry is present.

Comment 26

[Dave Townsend [:mossop]]

Re-requesting blocking because I no longer think I understand what the problem is here so it needs re-evaluation.

Comment 27

[Tony Mechelynck [:tonymec]]

Looks related with bug 579513 except the latter was FIXED on 2010-07-19. Regression?

Comment 28

[Dave Townsend [:mossop]]

(In reply to comment #27)
> Looks related with bug 579513 except the latter was FIXED on 2010-07-19.
> Regression?

That was purely about add-ons in the application directory and so is likely unrelated

Comment 29

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

In comment 0 Aaron mentions a 4.0b3pre build. Given my bug 581518 from yesterday I got the idea to test it with a recent Minefield build instead of beta2. And that 100% reveals this bug. All the time the Tool menu entries aren't shown. So I assume we also suffer from bug 571193 here. But I wonder why we do not get any error displayed in the error console.

Comment 30

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

Regressed between the builds 10072103 and 10072203:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1ac07fe5f6c9&tochange=0f5fc40c6a0f

Because that's an OS X only bug, I only see bug 571193 as the culprit here.

It only happens for a special set of add-ons. Adblock Plus's entry is still shown in the Tools menu. I wonder if this is related to add-ons with binary components - Adblock Plus doesn't have one.

Comment 31

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

Attachment: Sample XPI

The reason here are the targetPlatform entries inside the install.rdf. Once I remove those the Tools menu is shown:

<em:targetPlatform>Darwin_x86-gcc3</em:targetPlatform>
<em:targetPlatform>Darwin_x86_64-gcc3</em:targetPlatform>
<em:targetPlatform>Linux_x86-gcc3</em:targetPlatform>
<em:targetPlatform>Linux_x86_64-gcc3</em:targetPlatform>
<em:targetPlatform>WINNT_x86-msvc</em:targetPlatform>  

I have stripped down GrafxBot so it can better be used as an example. In the above mentioned window no Add-ons Manager patches have been landed. So I still think it's a file system issue when evaluating the targetPlatforms?

Comment 32

[Aaron Train [:aaronmt]]

This issue has resolved itself for me with bug 581518 with testing the original add-on.

http://hg.mozilla.org/mozilla-central/rev/3559a37d183f

Across these two builds: 

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100726 Minefield/4.0b3pre
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9pre) Gecko/20100726 Namoroka/3.6.9pre

Henrik, are you able to reproduce now? If not, this bug is resolved.

Comment 33

[Dave Townsend [:mossop]]

So did this bug only reveal itself when using profiles with absolute locations? That might explain why I never saw it and the relevant tests are passing.

Comment 34

[Aaron Train [:aaronmt]]

I believe so. The difference I am seeing now is that my [ExtensionDirs] and [ThemeDirs] are being rebuilt with absolute paths when I re-open Minefield.

Comment 35

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

So it has been fixed by bug 581518. Marking as verified fixed.