Closed Bug 1782755 Opened 3 years ago Closed 3 years ago

Firefox doesn't relaunch / restore automatically after MacOS restarts for updates

Categories

(Core :: Widget: Cocoa, defect, P3)

Product:
Core
Component:
Widget: Cocoa
Platform:
Unspecified
macOS
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 639707

People

(Reporter: adavis, Unassigned)

References

Details

My MBP (M1 chip) ran updates and restarted over the weekend. Every application and browser was restored except for Firefox Nightly 105.0a1 (2022-07-29) (64-bit) and Firefox release 103.0 (64-bit).

Steps to reproduce

  • Update Mac OS (w/ automatic restart)

Expected Results

  • Firefox reopens / restores

Actual Results

  • Firefox remains closed
  • User must launch Firefox manually

The Bugbug bot thinks this bug should belong to the 'Toolkit::Application Update' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: General → Application Update
Product: Firefox → Toolkit

I wasn't able to reproduce this myself, although I don't have an M1 chip. I'm not sure there's any macOS logs for this sort of thing either :(. A couple of things we can check though:

  • Do you have any entries in about:crashes around the time of the restart?
  • Do you have any updates applied around the time of the restart (you can find the update history in about:preferences)
Flags: needinfo?(adavis)

I don't have any crashes and there weren't any browser updates around that time.

Speaking to Romain this morning, it seems to be a known issue in regards to restarts on Mac related to updates specifically. I'll ni? in case he has more context to share or if there are existing bugs already open on the topic.

I'll also trying to reproduce on an Intel based Mac that I have. It so happens it needs to be updated. I'll post the outcome here.

Flags: needinfo?(adavis) → needinfo?(rtestard)

Re -adding my ni? to circle back with my test results.

Flags: needinfo?(adavis)

I confirm that when updating Mac OS on my Intel based MBP, neither Firefox Nightly nor Release restarted.

In contrast, if I do a manual reboot of the machine, Firefox Release will restart (but not Nightly).

Flags: needinfo?(adavis)

I have an older Intel MBP that I tried this on a few days ago - Firefox release restarted successfully after an update. However, this was an update that I forced -- not one that happened automatically in the background.

(In reply to Alex Davis [:adavis] from comment #3)

I don't have any crashes and there weren't any browser updates around that time.

Speaking to Romain this morning, it seems to be a known issue in regards to restarts on Mac related to updates specifically. I'll ni? in case he has more context to share or if there are existing bugs already open on the topic.

I'll also trying to reproduce on an Intel based Mac that I have. It so happens it needs to be updated. I'll post the outcome here.

I was mentioning Windows 11 where I just tested that it does not restart Firefox in this case (OS restart as a consequence of an update when Firefox is opened) - do we have a Windows bug for this?

Flags: needinfo?(rtestard)

(In reply to Romain Testard [:RT] from comment #7)

(In reply to Alex Davis [:adavis] from comment #3)

I don't have any crashes and there weren't any browser updates around that time.

Speaking to Romain this morning, it seems to be a known issue in regards to restarts on Mac related to updates specifically. I'll ni? in case he has more context to share or if there are existing bugs already open on the topic.

I'll also trying to reproduce on an Intel based Mac that I have. It so happens it needs to be updated. I'll post the outcome here.

I was mentioning Windows 11 where I just tested that it does not restart Firefox in this case (OS restart as a consequence of an update when Firefox is opened) - do we have a Windows bug for this?

Yeah, https://bugzilla.mozilla.org/show_bug.cgi?id=1778562 tracks this issue on Windows. It's definitely a different root cause than on macOS, though.

(In reply to Romain Testard [:RT] from comment #7)

I was mentioning Windows 11 where I just tested that it does not restart Firefox in this case (OS restart as a consequence of an update when Firefox is opened) - do we have a Windows bug for this?

As I just mentioned in Bug 1778562, this feature in fact does work on Windows. But Windows only enables this behavior on unattended restarts (generally for OS updates). Not manual restarts, whether for OS updates or not. This is described in more detail in Bug 1778562 Comment 1.

It's unclear how many of these OS shutdowns are tied to updates but it seems that the top thing closing the browser on Mac is the OS. (Mac users tend to keep the browser open)
https://sql.telemetry.mozilla.org/queries/87239/source#216165

P3 S3: UX annoyance.

Severity: -- → S3
Priority: -- → P3

I would classify this as more than a UX annoyance. It's most certainly going to be impacting our days of use metric on MAC. If other browsers re-open and we don't, we're inviting our users to use our competitors.

There's so much evidence that making it easy to get back into our browser is important (think pinning and setting to default), this seems directly along those lines. Our browser is closing on users! (whether it's our fault or not)

:adavis gotcha, I'll bring this up in the DI weekly to get a sense of how this should be prioritized.

Thanks so much :nrishel

:adavis quick follow up, we're going to leave this P3 S3 while :bytesized does initial investigation and while we verify telemetry to get a scope of the impact. We can update once those are better understood.

I spent some time trying to look into this, but I'm not very knowledgeable about or experienced with macOS development so I didn't make a lot of progress. Then I came back and reread the bug and realized that the only reason our team is looking at this in the first place is that the Bugbug bot saw the word "update" and put the bug in Toolkit::Application Update even though the update in question is a macOS update, not a Firefox application update. This bug doesn't really have anything to do with Application Update. And it would probably make more sense for someone that knows more about macOS development to look into this.

Severity: S3 → --
Component: Application Update → Widget: Cocoa
Priority: P3 → --
Product: Toolkit → Core
Severity: -- → S3
Priority: -- → P3

It's unclear how many of these OS shutdowns are tied to updates but it seems that the top thing closing the browser on Mac is the OS. (Mac users tend to keep the browser open) https://sql.telemetry.mozilla.org/queries/87239/source#216165

It's unclear what was measured exactly here, but notice that on other operating systems "close-button" is 55-70% of the closures, whereas it's 0% on macOS. IIRC on macOS the close button really minimizes, so that's likely the explanation. If you factor that in, I'm not sure there's any indication macOS users behave differently here, i.e. that "OS" just ranks higher because macOS doesn't fully exit applications by default.

macOS has ~65% closed by OS. If I halve that (to account for the missing "50% close-button"), I end up at ~32%, which seems fully in line with other operating systems.

Flags: needinfo?(adavis)

There's an argument to be made here about perceived startup performance though. Haik told me that on modern macOS (by default) you don't even get a hint the application was already running, which would make us look slower.

(In reply to Gian-Carlo Pascutto [:gcp] from comment #17)

It's unclear how many of these OS shutdowns are tied to updates but it seems that the top thing closing the browser on Mac is the OS. (Mac users tend to keep the browser open) https://sql.telemetry.mozilla.org/queries/87239/source#216165

It's unclear what was measured exactly here, but notice that on other operating systems "close-button" is 55-70% of the closures, whereas it's 0% on macOS. IIRC on macOS the close button really minimizes, so that's likely the explanation. If you factor that in, I'm not sure there's any indication macOS users behave differently here, i.e. that "OS" just ranks higher because macOS doesn't fully exit applications by default.

macOS has ~65% closed by OS. If I halve that (to account for the missing "50% close-button"), I end up at ~32%, which seems fully in line with other operating systems.

I don't have any data on what % of people know their apps are still open vs not. I can't speak for any measurements in this area. I understand your math but there are assumptions there and potentially other variables at play. For example, I don't feel compelled to close applications on my Mac. It never noticeably slows down. In contrast, I do feel compelled to close them on my super-powerful Windows computer. Somehow, it still manages to get slow and I need to regularly close apps.

When my laptop restarts for an update once a month, I'm greeted by Chrome and Safari if they were (knowingly or not) left open before restart. It's just easier for me to start browsing with them because Firefox doesn't re-open. It's not top of mind. This is a monthly invitation to start using our competitors more and to use Firefox less. You can be sure that Safari and Chrome will try to seek the default browser position from our users. Safari asks me every other time I use it.

If we optimistically only lose 0.1% of our users every time there's an update, it adds up after 1 year. There were 10-12 updates in 2022. We could lose ~1% of users to updates.

We regularly lose our users to our competitors in scenarios like this. We observe the impact of Edge hijacking search results on Bing. We observe the same thing on sites where Firefox can be downloaded on 3rd party but when you click download, it opens Brave or Chrome downloads. This is less extreme but along those lines.

As mentioned above, we know that removing friction to get users back into Firefox is extremely important (e.g. pins, defaults, etc). Our competitors are doing a great job at staying top of mind and in view. This is just one more hole for us to plug.

Flags: needinfo?(adavis)

This bug is essentially a duplicate of bug 1326181 and/or bug 639707. I'm hesitant to simply close this bug as duplicate since there is telemetry here that we didn't have before, as well as valuable thoughts in comment 19. I will take a look tomorrow to see what's needed to drive bug 639707 over the finish line.

Depends on: 1326181, 639707

Alex, I see that you commented in bug 639707 comment 12 before. Do you want to capture your additional thoughts and telemetry there and close this bug as a duplicate?

Flags: needinfo?(adavis)

I believe I have a fix for this in bug 639707 and I'm going to add better telemetry to measure how often we are being restored by macOS vs. users manually launching Firefox.

Status: NEW → RESOLVED
Closed: 3 years ago
Duplicate of bug: 639707
Resolution: --- → DUPLICATE
Flags: needinfo?(adavis)
You need to log in before you can comment on or make changes to this bug.