Closed Bug 757978 Opened 8 years ago Closed 8 years ago

Uninstalling Firefox leaves behind a Nightly\webapprt folder

Categories

(Firefox :: Installer, defect)

x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 18
Tracking Status
firefox15 --- disabled
firefox16 - affected

People

(Reporter: bbondy, Assigned: TimAbraldes)

Details

(Whiteboard: [Desktop WebRT])

Attachments

(1 file)

After uninstalling Firefox I still see these 2 folders:
C:\Program Files (x86)\Nightly\webapprt\
C:\Program Files (x86)\Nightly\webapprt\components

I haven't tested on other channels (I think webapps is already on Aurora too so that would probably be affected as well)
Yes, same for Firefox 14.0a2 but there some more directories are left behind.
Component: Installer → Webapp Runtime
QA Contact: installer → webapp-runtime
(In reply to Henrik Skupin (:whimboo) from comment #1)
> Yes, same for Firefox 14.0a2 but there some more directories are left behind.

Webapps support was disabled in FF 14. Can you confirm that a FF Beta build is affected by this? Otherwise, only FF 15 or later will be affected.
Checking my beta build, this appears not happen there, given that we backed out before the merge to beta.
Component: Webapp Runtime → Installer
QA Contact: webapp-runtime → installer
Whiteboard: [Desktop WebRT]
Nominating for k9o - we really should be doing a clean uninstall for when firefox is uninstalled - nothing left for webrt on uninstall.
blocking-kilimanjaro: --- → ?
blocking-kilimanjaro: ? → -
Investigating
Assignee: nobody → tabraldes
blocking-kilimanjaro: - → ---
Not sure why these flags got changed when I took the bug.  Removing the tracking flag, but I can't seem to set the blocking-kilimanjaro flag back to "-"
Status: NEW → ASSIGNED
There are 2 issues causing this bug:
  1) The installer is creating an empty "webapprt\components" directory in the Firefox installation dir
  2) The uninstaller is failing to remove that empty directory

It's easy enough to explicitly remove the empty dir from the uninstaller.  Now I just need to track down what's causing the dir to be created in the first place.
Ya I think the dir shouldn't exist in the first place. I think there are files there in the staging dir but they get packaged to an JAr file.  The blank dir remains, maybe it should be removed at staging time.

See toolkit\mozapps\installer\packager.mk
This simple change removes the empty webapprt subdirectory during Firefox uninstallation.  Modifying PACK_OMNIJAR_WEBAPP_RUNTIME is an option for preventing the creation of webapprt and webapprt\components, but it might be more trouble than it is worth.
Comment on attachment 635112 [details] [diff] [review]
Patch v1 - Remove empty webapprt dir when uninstalling Firefox

Spoke offline with Robert about this.  We'll land this patch to deal with the immediate issue and file a followup to make sure that empty directories aren't included in the installer.
Attachment #635112 - Flags: review?(robert.bugzilla)
What's the user impact here? Just want to make sure this is worth tracking, and isn't just a matter of correctness.
(In reply to Alex Keybl [:akeybl] from comment #11)
> What's the user impact here? Just want to make sure this is worth tracking,
> and isn't just a matter of correctness.

I believe the impact here is just leaving two empty folders behind on an uninstall of Firefox. Tim - Can you confirm?
(In reply to Jason Smith [:jsmith] from comment #12)
> (In reply to Alex Keybl [:akeybl] from comment #11)
> > What's the user impact here? Just want to make sure this is worth tracking,
> > and isn't just a matter of correctness.
> 
> I believe the impact here is just leaving two empty folders behind on an
> uninstall of Firefox. Tim - Can you confirm?

That's correct
Thanks - we'll track, but wouldn't block on this.
If this is left unfixed after our first beta (going to build Monday/Tuesday), we'll likely untrack.
Attachment #635112 - Flags: review?(robert.bugzilla) → review+
Tested by installing this try build [1], verifying that the offending directories were created, then uninstalling and verifying that the offending directories were not left over.

Inbound is currently closed, but whenever it opens back up I'll land this patch.

[1] https://tbpl.mozilla.org/?tree=Try&rev=71d111bacf7d
Target Milestone: --- → Firefox 17
Target Milestone: Firefox 17 → Firefox 18
https://hg.mozilla.org/mozilla-central/rev/cc8bc4e1bdfc
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.