Closed Bug 245553 Opened 16 years ago Closed 16 years ago
Note breaks Firefox
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040411 Firefox/0.8.0+ (best browser EVAR1!!) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040603 Firefox/0.8.0+ After uninstalling QuickNote (via new EM's Uninstall feature), on first restart of Firefox, the Bookmark toolbar no longer work and Firefox is almost un-responsive (ie. menus aren't clickable etc). Looking into profile directory, the QuickNote files are deleted, but references to it in chrome.rdf and overlayinfo\..\overlays.rdf are left untouched. Reproducible: Always Steps to Reproduce: 1. Install QuickNote from given URL. 2. Restart 3. Open EM, uninstall QuickNote 4. Restart Actual Results: Bookmark Toolbar is empty, menus are not clickable, references to QuickNote left in profile. Expected Results: Remove all references it created, and start up normally. Some extensions are uninstalled ok, including Pike's Show Failed URL, All-in-One gestures.
Had the same problem when I uninstalled the 0.9 compatbile Adblock
Severity: normal → major
Forgot to mention that was an installer build. Perhaps should be blocking0.9? The release should not have a bad extension-related bug as it had with 0.8...
Are you sure you tested it with a branch (Aviary) build? I see you requested 0.9 blocking which means that the bug appears on a branch build. However, using http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-06-04-09-0.9/FirefoxSetup.exe, I noticed that the provided extension cannot be installed (it doesn't appear on the EM). So, wrt Firefox 0.9-1.0 branch, this bug is invalid.
Using the Firefox build from comment #3 and the 0.5.8 build of QuickNote causes the same issue: (QN 0.5.8: http://jedbrown.net/dev/Mozilla/quicknote_dev_0_5_X_ff0.9.xpi)
I downloaded this nightly: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-06-03-12-0.9/FirefoxSetup.exe The extension appeared in the EM for me. It _has_ 0.9's install.rdf. I thought trunk builds were still using old EM, weren't they?
I can reproduce this with a dummy extension with an overlay. Ben, we need to delete chrome.rdf and the overlayinfo when we uninstall extensions.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking0.9? → blocking0.9+
On today's (June 5th) windows .zip Aviary build, the QN installs correctly, and on un-install screws up Firefox on first restart, then on the 2nd or 3rd restart, Firefox goes back to normal (working), although varies on which startup. I too believe it is a chrome.rdf and overlay issue.
Make Extension Manager handle chrome registration arcs that don't include the provider name, e.g. <em:content>content/</em:content> by inspecting the contents.rdf at that location and gleaning provider names from it. Then ensure that the Chrome Registry also handles overlaid stylesheets provided by the extension and removes them correctly when the extension is uninstalled.
Fixed in the EM, which is branch only.
Status: NEW → RESOLVED
Closed: 16 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: --- → Firefox0.9
It no longer hangs on startup. Great! Though I noticed Firefox still leaves references to QN in chrome\chrome.rdf. While it isn't very bad, I think ideally they should be deleted too.
Uninstalling this XPI causes the dead toolbars and the following message in the console: *** Failed to load overlay chrome://testext/content/testextOverlay.xul on: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+ I'll reopen this bug, please let me know if you want me to file a different bug instead.
bah! ok thanks for the test case pike.
Bah. Your contents.rdf is malformed. your package URI is urn:mozilla:package:testext and yet your chrome:name arc is "showfailedurl" contents.rdf problem, not a EM problem.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
I think I'll give up on testcases I'm not having much luck lately, sorry for wasting your time Ben.
You need to log in before you can comment on or make changes to this bug.