Closed Bug 1600905 Opened 4 years ago Closed 4 years ago

Unusual behavior after reinstalling Firefox over an opened one

Categories

(Firefox :: Installer, defect, P1)

Desktop
Windows
defect

Tracking

()

VERIFIED FIXED
Firefox 73
Tracking Status
firefox-esr68 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- verified

People

(Reporter: atrif, Assigned: molly)

References

(Regression)

Details

(Keywords: regression)

Attachments

(5 files)

Affected versions

  • 71.0-build5 (20191202093317)
  • 72.0b1 (20191202142314)
  • 73.0a1 (20191202091209)

Affected platforms

  • Windows 10x64

Steps to reproduce

  1. Download Firefox 73.0a1.exe and install it.
  2. Open the installed Firefox.
  3. Reinstall the build from Step1 on the same location while Firefox is opened.
  4. After the installation is completed launch Firefox.
  5. Open a new tab and try to load a page.

Expected result

  • New Firefox window works as expected (or maybe not installed?).

Actual result

  • Firefox is directly opened and many-core functionalities don’t work (loading a new webpage in a new tab, closing Fx from the “X” button, closing tabs, right-clicking brings an unusual context menu)

Regression Range

  • Reproducible on Firefox 69.0.3 (20191009172106). I will search for one ASAP.

Notes

  • Attached a console log from the browser while affected by this.
  • Attached a screen recording.
  • This issue once occurred to me after updating to the latest Nightly but I don’t have STR for this. I tried reproducing this issue when updating this but with no luck. Also, maybe worth mentioning that I had “Restore last session checked” and multiple windows opened across two monitors. Maybe some processes didn't correctly close while Firefox update was applied and led to this behavior.
Attached image browser_.gif
Component: DOM: Core & HTML → Installer
Product: Core → Firefox

Hmm, this doesn't reproduce for me; what I'm seeing is that trying to launch the browser again after the second install just gets me a new window in the already running instance, which is the expected behavior. I don't think having multiple windows already open should affect anything. Anything else you can identify about the specific circumstances that this happened under would be very helpful.

Yes, you are right, sorry for not saying this in the first place. The new window opened after clicking "Finish" with "Launch Firefox Nightly now" checked has buggy behavior. I made a screen recording for a better understanding.
These are the STR I follow in the recording:

Precondition

  • Have Firefox installed and open.

STR:

  1. Install firefox over the already opened one on the same path.
  2. After the installation is complete click the "Finish" button while having "Launch Firefox Nightly now" checked.
  3. Open a new tab on the new opened window and try to load web content in it (the page never loads and random buggy behaviors occur like can't close tabs or browser by pressing X, long context menu...etc).
    As a side note, I'm installing the latest Nightly first and reinstalling it over the opened one.

Also, I can't reproduce this when updating and that happened only one time for me on the home computer, and I don't know exact STR for that. If there's anything I can help with please let me know.

I can reproduce this now, sorry about before. I'm about to check this, but my first guess is that this might be a regression that started with bug 1581002.

Nope, that's definitely not it, backing out that patch doesn't help anything. Still investigating.

Found the problem. We're not actually supposed to allow the install to run if that copy of Firefox is already running, but the detection that it's already running has broken. This was caused by bug 1518639 because the final check we were doing is to look for a window of the class FirefoxMessageWindow, but that bug removed the window which used that class. We'll have to switch to checking for either one of MozillaWindowClass or MozillaDialogClass, because there doesn't seem to be any window class that always exists anymore (there's MozillaHiddenWindowClass but the hidden window isn't created by, for example, the profile manager). Alternatively, we could use an entirely different method of determining whether Firefox is running, like looking for running processes with the main executable as their image, but that's hard to do from NSIS, and we'd have to account for things like firefox.exe having been moved (as might happen during an update), so I don't think it's worth it.

Assignee: nobody → mhowell
Status: NEW → ASSIGNED
Priority: -- → P1
Regressed by: 1518639

We've been using the "FirefoxMessageWindow" class for this, but it no longer
exists as of bug 1518639, so switch to classes that should always be there.

(In reply to Molly Howell (she/her) [:mhowell] from comment #6)

We'll have to switch to checking for either one of MozillaWindowClass or MozillaDialogClass, because there doesn't seem to be any window class that always exists anymore

Doesn't it mis-detect Thunderbird (or any other Gecko-based apps) or another instance of Firefox installation?

Old regression and an edge case, wontfix for releases in flight, any incoming fix will ride the trains.

Pushed by mhowell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/909813da43e0
Use the right window classes to detect if a Firefox instance is running. r=agashlin

(In reply to Masatoshi Kimura [:emk] from comment #8)

(In reply to Molly Howell (she/her) [:mhowell] from comment #6)

We'll have to switch to checking for either one of MozillaWindowClass or MozillaDialogClass, because there doesn't seem to be any window class that always exists anymore

Doesn't it mis-detect Thunderbird (or any other Gecko-based apps) or another instance of Firefox installation?

Yes, it almost certainly would. I'm okay with that because it's a secondary check that runs only after we've determined that the specific installation we're interested in has files that are known to be in use (for the pre-install check that this bug is about, anyway; there's a separate post-install check but I'm planning to remove that altogether in bug 1601806).

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 73
Attached image installer_error.gif

Hello!
Tried verifying today with latest nightly installer.
The issue itself is fixed when trying to install Firefox on an already running one an error is presented, as seen in the screenshot and screen recording.

But there is a new problem here. Even if the Firefox Nightly is closed, after the installation is completed and clicking "Finish" button while having "Launch Firefox Nightly now" checked and there are no other instances of Firefox opened there is an "Firefox is already running" error presented as seen in the attached screen recording.
From what I see this error is presented every time, even if the Firefox is installed to a custom location on an empty folder and even if there are no other Firefox installations on the system. Should I file a new bug on this matter and close this one? Thanks!

Flags: needinfo?(mhowell)

(In reply to Alexandru Trif, QA [:atrif] from comment #13)

Should I file a new bug on this matter and close this one? Thanks!

Hmm. Please file a new bug and mark it as a regression from this one. I'll look into this in the meantime. Thanks.

Flags: needinfo?(mhowell)

Actually never mind, I think I'll fix this by going ahead and doing bug 1601806 (which will just remove the check that you're hitting because I don't think we need it anymore).

Flags: qe-verify+

Retested with 73.0b3 (20200110003145) installer on Windows 10. Firefox cannot be opened if another instance is running so closing this as verified and removing qe+. The problem from comment 13 seems to be solved on bug 1601806.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.