Closed Bug 1112937 Opened 5 years ago Closed Last year

[Win] Firefox can update while still running when using multiple profiles concurrently

Categories

(Toolkit :: Application Update, defect, P2)

Unspecified
Windows
defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox56 + wontfix
firefox57 - fix-optional
firefox58 --- affected

People

(Reporter: billm, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 3 obsolete files)

STR:
1. Somehow set up a FF installation in $FF that will update the next time you start it.
2. Create two empty profiles.
3. Start $FF/firefox -profile $PROF1 -no-remote
4. Go to About Nightly and wait until it downloads and applies the update.
5. Open a terminal and cd into $FF.
6. Start $FF/firefox -profile $PROF2 -no-remote

Actual result:
The update has been applied while the Firefox instance in step 3 was running. If you run |ls| in the terminal in step 5, you'll see nothing because the directory is empty. The log in $FF/updates/last-update.log will show that an update took place. If the Firefox instance in step 3 tries to run, say, plugin-container, it will run the new version and probably crash.

Expected result:
The update should not be applied while any instances are running.

I realize that it's not common for users to run the same binary with two profiles. However, it seems like some new features are coming down the pipeline where we want to use multiple profiles, so we probably want to support this.
With content processes becoming more of a thing with e10s, I can see this biting us harder over time.

We might want to consider not doing the directory-swap thing after an update unless we're certain there's not another active Firefox process running.

Thoughts, rstrong?
Flags: needinfo?(robert.strong.bugs)
OS: Linux → Unspecified
Hardware: x86_64 → Unspecified
Already discussed this with bsmedberg and I've got a couple of ideas of how to address this. Will likely look into it next week.
Flags: needinfo?(robert.strong.bugs)
Not enough time / resources to take this on :(
Duplicate of this bug: 1322850
See Also: → 1305530
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
Depends on: 1349894
No longer depends on: 1349894
Quick update... I've been able to spend some time on a Windows fix for this. I have the code finished for updater.cpp and the tests. I still have to finish the UI code and hope to be able to within the next week.
Using this bug for the Windows fix. A fix for other platforms will require a different approach.
OS: Unspecified → Windows
Summary: Firefox can update while still running when using multiple profiles concurrently → [Win] Firefox can update while still running when using multiple profiles concurrently
Tracking for 56 since this may land for 56 and we may need manual testing help.
Flags: qe-verify+
This bug really drives me crazy!  BTW, I once have seen a message in Options (or somewhere) that "another instance of Firefox is taking care of updates".  It made me believe this was fixed.  But it definitely isn't.
Same for me. The major problem is that if Firefox gets updated via another profile, my always open instance of Firefox will crash in specific situations because the parent buildid doesn't match the content buildid.
We are heading for release day next week, so I'm assuming this is a wontfix for 56. 
Is it still on the radar for 57/58?
Robert, can you update on status here?

I'm going to set 57 fix-optional because this is a long standing issue and I don't think we would want to add risk by uplifting a fix to beta.
(In reply to Julien Cristau [:jcristau] from comment #13)
> Robert, can you update on status here?
Flags: needinfo?(robert.strong.bugs)
Comment on attachment 8912869 [details] [diff] [review]
patch 2 - client and test changes - in progress

Forgot to update the service tests which is trivial so I'll resubmit
Attachment #8912869 - Attachment is obsolete: true
Fixes all but marAppInUseFailureCompleteSvc_win.js
Assignee: robert.strong.bugs → ksteuber
Attachment #8912867 - Attachment is obsolete: true
Attachment #8912883 - Attachment is obsolete: true
Assignee: ksteuber → nobody
Status: ASSIGNED → NEW
wontfixing for now, bug 1366808 is the current approach.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.