310010 - DOM Inspector from Firefox prior to 1.0 cannot be uninstalled in 1.4 and above

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Agro Rachmatullah]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Before installing 1.5 Beta 1 I uninstalled 1.0.6. The 1.0.6 has DOM Inspector
installed. When installing 1.5 Beta 1 I also chose to install DOM Inspector.
After installing 1.5 Beta 1, there still exists the extension "DOM Inspector
1.0" (leftover of previous Firefox, disabled) eventhough there also exists "DOM
Inspector 1.8b4". If I uninstall "DOM Inspector 1.0", after restarting Firefox
the extension still exists on the list of extensions (although couldn't be
"uninstalled" anymore).

Reproducible: Always

Steps to Reproduce:

Comment 1

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

This sounds like it may very well be the DOMi version of bug 295855. If so, I
suspect we may have to "one off" this during the upgrade as was done in bug
295855 for the abandoned default theme dir.

Comment 2

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

I wasn't able to reproduce on Linux and I'll try win32 in a short while.

Reporter, there have been several fixes that have landed since the build you
used to report this. Could you try to reproduce this again with a recent nghtlty?

Comment 3

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

DOMi from 1.0.6 is not installed as an extension and is not displayed in the EM
ui. With 1.5, the betas, etc. DOMi is installed as an extension and is displayed
in the EM ui. It is possible that installing DOMi as an extension might cause
this behavior when upgrading. I tested upgrading a 1.0.6 win32 install with DOMi
to the latest nightly and was not able to reproduce this. Reporter, can you
confirm any of the above?

Comment 4

[Agro Rachmatullah]

I'll try it again with the latest nightly and post the results.

PS: I'm confused, why is the nightly build named 1.6??

Comment 5

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

You may be looking at a trunk build and for this it would be best to test with
the branch which will become 1.5.
http://mozilla.osuosl.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/

If this was caused by installing one of the DOMi extensions floating around
chances are it was caused by it not being packaged properly and just installing
the update won't necessarily fix this though I highly suspect if you created a
new profile with 1.0.6 and then upgraded from 1.0.6 that you would not
experience this error.

Comment 6

[Agro Rachmatullah]

Tried with Beta 1 and Pre Beta 2 [Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8b5) Gecko/20051002 Firefox/1.4.1]. The bug still persist.

0) Windows XP SP2 with no previous Firefox installation
1) Install 1.06 in custom mode and choose to install all optional components
(including developer tools).
2) Uninstall 1.06.
3) Install 1.5 Beta 1 (or latest build) in custom mode and choose to install all
optional components (including developer tools).
4) On startup Firefox will inform that the extension "DOM Inspector 1.0" is
incompatible and will be disabled.
5) Go to the extension manager, and try to uninstall "DOM Inspector 1.0".
Firefox will inform that the extension will be uninstalled after restarting Firefox.
6) Restart Firefox.
7) Go to the extension manager. "DOM Inspector 1.0" will still be listed
(disabled). Cannot uninstall anymore.

Comment 7

[Reed Loden [:reed]]

Confirmed bug on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050908 (No IDN) Firefox/1.4 ID:2005090806

I was able to click the "Uninstall" button for it one time but after I restarted
Firefox, the "Uninstall" button was grayed out and unable to be used anymore. It
didn't actually uninstall it; it just said it was going to.

This is definitely a bug.

Comment 8

[Agro Rachmatullah]

Uhm, actually the bug is nonexistant with the latest build (Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051002 Firefox/1.4.1). I
tried this on a machine WITHOUT firefox installed:

1) Install firefox 1.0.6 with DOM inspector
2) Uninstall firefox 1.0.6
3) Install firefox 1.5 latest build (version number shown above) with DOM inspector

Upon startup, firefox won't complain that "there is an incompatible extension"
and DOM 1.0 isn't even listed on the extensions list. Nice.

However if you do this:

1) Install firefox 1.0.6 with DOM inspector
2) Uninstall firefox 1.0.6
3) Install firefox 1.5 beta 1 with DOM inspector
4) Try to uninstall DOM inspector 1.0 (won't work)
5) Uninstall firefox 1.5 beta 1
6) Install firefox 1.5 latest build with DOM inspector

Then DOM inspector 1.0 will stay forever on the extension list.

Comment 9

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

Still not able to reproduce. I did the following:
1) installed 1.0.6 (selected Custom during the install and selected Developer
Tools so DOMi would be installed)
2) started Firefox with a new profile. I opened DOMi to verify it was installed.
I opened the EM to verify it *wasn't* listed since DOMi is not packaged as an
extension with 1.0.6.
3) Uninstalled 1.0.6 using Add or Remove Programs.
4) Installed Firefox 1.5 Beta 1 (selected Custom during the install and selected
Developer Tools so DOMi would be installed)
5) Let the installer launch Firefox. I opened DOMi to verify it was installed. I
opened the EM to verify DOMi 1.8b4 *was* listed since DOMi is now packaged as an
extension. There were no additional entries for DOMi.

It would help if someone that has reproduced this could please attach the
extensions.rdf file (all lowercase) from inside their profile directory and the
old Extensions.rdf (first letter is uppercase) from their profile's extensions
directory. It is preferable if these are from a new profile so there is less
information to go through in the file.

Information regarding how to find the profile directory
http://kb.mozillazine.org/Profile_folder

Comment 10

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

If someone that is able to reproduce this could attach the two files asked for
in comment #9 I will take a look at what is happening... this is still wfm.

Comment 11

[Reed Loden [:reed]]

(In reply to comment #9)

> 3) Uninstalled 1.0.6 using Add or Remove Programs.

Try it WITHOUT uninstalling. You shouldn't have to uninstall anyway, imho.
I didn't uninstall it, and it happened to me.

Comment 12

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

I have tried it without installing without being able to reproduce this on both
win32 and linux... 1.0.6 to 1.5 beta 1 and beta 2. The steps I wrote were from
following the steps in comment #8 but I have tried to reproduce this with
several variations. Can you please attach the files asked for in comment #9? Thanks

Comment 13

[Reed Loden [:reed]]

Attachment: Extensions.rdf (from my current profile)

Comment 14

[Reed Loden [:reed]]

Attachment: extensions.rdf (from my current profile)

Comment 15

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

OK now we are getting somewhere - some builds prior to 1.0 included DOMi as an
extension. With 1.0 it was no longer included as an extension and now that it is
once again included as an extension the EM is having difficulty with reconciling
the old vs. new DOMi metadata.

Here is one of many hits I found searching on the old GUID for DOMi which is
{641d8d09-7dda-4850-8228-ac0ab65e2ac9}. Read oldtimer's post.
http://forums.mozillazine.org/viewtopic.php?p=739291

I suspect this problem cannot be reproduced with a clean install of 1.0.x (e.g.
deletion of the entire Mozilla Firefox directory in program files on win32) and
then upgrading to 1.5 beta 1.

Comment 16

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

Also, include creating a new profile when trying to recreate this. I suspect it
will be easy to fix in the same manner as the default theme issue was fixed in
bug 295855

Comment 17

[Reed Loden [:reed]]

Since there are probably a lot of people that have used Firefox pre-1.0, this
would be a good bug to fix before 1.5 release (and people actually notice it
more). Requesting blocking1.8rc1.

Comment 18

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

Reed - could you check if there is a directory named
{641d8d09-7dda-4850-8228-ac0ab65e2ac9} in your Firefox application's extensions
directory?

btw: turns out it isn't having trouble reconciling the metadata between the old
and new versions of DOMi... the new version has a different id so there are no
conflicts. I was able to simulate reproducing this on linux (will try win32 in a
short while) when the {641d8d09-7dda-4850-8228-ac0ab65e2ac9} directory in the
app's extensions directory is not removed. The reason it can't be uninstalled is
that it has em:locked="true". This could have been avoided if we had used the
original ID / GUID for DOMi that was used previously. :/

Comment 19

[Reed Loden [:reed]]

Nope, I don't have a directory named {641d8d09-7dda-4850-8228-ac0ab65e2ac9}.

(This is from looking in my C:\Documents and Settings\Reed Loden\Application
Data\Mozilla\Firefox\Profiles\default.ilf\extensions\)

Comment 20

[Reed Loden [:reed]]

I suspect (complete guess) the directory was removed when I clicked the
"Uninstall" button the first time; however, it seems that some of the remnants
are still leftover from that failed uninstall (which is now set as em:locked so
I can't try to uninstall again).

Comment 21

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

In the "Firefox application's extensions directory" which is by default
c:\program files\mozilla firefox\extensions on windows but you could have chosen
a different location during the install. Look in there for a directory named
{641d8d09-7dda-4850-8228-ac0ab65e2ac9}

Comment 22

[Reed Loden [:reed]]

I've left that computer for now (it's downstairs). Tomorrow morning, I can get
the information and post it. Is that ok?

Comment 23

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

No problem, I just verified that the directory is there.

btw: this should only affect win32 and 1.5 branch or trunk

Comment 24

[Reed Loden [:reed]]

oh, sorry... I had requested that change. I thought you had said that you had
somehow reproduced it on Linux. My fault. :)

Comment 25

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

Attachment: patch - clean up DOMi from before Firefox 1.0

What's happening is some people have the same profile from before 1.0 when DOMi
was packaged in the same way as the default theme and just like the default
theme a copy of the DOMi dir with the install.rdf is copied to the profile's
extensions directory. Now that the EM supports installing by dropping an
extensions's directory into the app's or profile's extensions directory both of
these items are being installed. The user then sees DOMi ver. 1.0 as well as
the newer version in the EM ui. They uninstall DOMi ver. 1.0, restart, the one
in the profile is uninstalled, and now the one in the app's extensions
directory is displayed in the EM ui. The user then finds they are unable to
uninstall it since it has em:locked="true" which is enforced for items with
this attribute in the app's extensions directory.

This patch should provide the following:
a) 1.0.x upgrade - will not see DOMi ver 1.0
b) Already upgraded and has tried to uninstall - will not see DOMi ver 1.0
c) Already upgraded and has not tried to uninstall - will see DOMi ver 1.0 and
be able to completely uninstall it

I'm unsure if this is right or all that's required for the installer and app
update to remove these files from the app's extensions directory but from the
digging around I believe it is.

Comment 26

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

btw: I have no problem not having the EM check for the old DOMi dir in the
profile's extensions directory on app upgrade since the user can uninstall that
one but I see no harm in doing so since it only runs once per profile. I see no
harm in having the installer cleaning up the old DOMi dir from the app's
extensions directory especially since it appears to already be doing this for
other directories that are no longer being used and do not cause a problem if
they are left behind unlike this instance.

Comment 27

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

Attachment: also fix leftover theme

I thought the installer already removed the default theme from the app's
defaults/profile/extensions directory... it doesn't! This is bad since on next
upgrade we will just end up with bug 295855 again.

Comment 28

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

Attachment: patch

last patch had the wrong paths :/

Comment 29

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

Fixed on trunk

Checking in mozilla/browser/installer/removed-files.in;
/cvsroot/mozilla/browser/installer/removed-files.in,v  <--  removed-files.in
new revision: 1.5; previous revision: 1.4
done
Checking in mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--
 nsExtensionManager.js.in
new revision: 1.161; previous revision: 1.160
done

Comment 30

[Scott MacGregor]

do we need corresponding tbird changes for this patch? (at least for the
extension files)

Comment 31

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

(In reply to comment #30)
> do we need corresponding tbird changes for this patch? (at least for the
> extension files)
Yes, I got sidetracked and won't have time to do this for a couple of hours. I
would like to verify what existed pre 1.0 as well so any issues similar to the
old pre 1.0 DOMi can also be addressed... do you know if there were any
extensions that fall into this category?

Comment 32

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

Attachment: Thunderbird patch

Patch for Thunderbird's removed-files.in

These two patches prevent what will appear to be extension / theme data
corruption - in some cases with 1.5 in others with the next extension version
bump. I suspect we'll have to have a new upgrade path in the EM due to these
items not being removed on install.

Comment 33

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

re-opening until the Thunderbird patch for the cleanup of the app dir
defaults/profile/extensions has landed

I verified this is fixed for Firefox on the trunk

Comment 34

[Scott MacGregor]

Comment on attachment 199132 [details] [diff] [review]
Thunderbird patch

Thanks a lot for the tbird patch Rob.

Comment 35

[Kevin Brosnan]

I noticed that I have two seperate Mozilla Quality Feedback Agents installed one
in the extensions dir and one in the components dir of c:\program files\Mozilla
Firefox\. If this is reproducible do you want to take care of it here or in a
new bug?

Comment 36

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

Kevin - that's bug 311717.

Thunderbird patch checked in on trunk

Comment 37

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

Comment on attachment 199132 [details] [diff] [review]
Thunderbird patch

Also needed for 1.5 to prevent bug 295855 from happening on new profiles.

Comment 38

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

Checked in on MOZILLA_1_8_BRANCH

Checking in mozilla/mail/installer/removed-files.in;
/cvsroot/mozilla/mail/installer/removed-files.in,v  <--  removed-files.in
new revision: 1.1.2.3; previous revision: 1.1.2.2
done
Checking in mozilla/browser/installer/removed-files.in;
/cvsroot/mozilla/browser/installer/removed-files.in,v  <--  removed-files.in
new revision: 1.1.2.5; previous revision: 1.1.2.4
done
Checking in mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--
 nsExtensionManager.js.in
new revision: 1.144.2.15; previous revision: 1.144.2.14
done

Comment 39

[Reed Loden [:reed]]

The fix for this bug caused bug 314684.