Open Bug 639707 Opened 9 years ago Updated Last month

Add resume session support on macOS

Categories

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

All
macOS
defect

Tracking

()

People

(Reporter: sgreenlay, Unassigned)

References

(Blocks 3 open bugs, )

Details

(Whiteboard: [fxgrowth], tpi:+)

Attachments

(1 file)

No description provided.
Okay, I had to poke around a little more to find docs describing this behavior.
Scott - can you clarify which feature you mean, re: the last two comments?
I would guess that this is the behavior we'd want to make sure it well supported:
http://www.tuaw.com/2011/07/22/os-x-lions-resume-feature-lets-you-pick-up-where-you-left-off/

For us that would mean closing firefox without any prompts and during the resume restoring the profile. Ideally we could also store state for each tab (scroll position, text entry etc...) but this may not be feasible.
The way I see it (though I might we wrong) it's like the session restore feature we already have, just faster because it's using OS features. So this would basically replace session restore on Lion. It should especially be way faster when rebooting, if one chooses to save and restore all windows.
I'm not sure about automatic termination, does anyone know how that works? Like, does the OS automatically terminate any apps that support resume?
Anyone with a Mac developer account (even the free one) can view the WWDC session on the subject of both Automatic Termination and Resume. Go to https://developer.apple.com/videos/wwdc/2011/ and look for "Resume and Automatic Termination in Lion".

To summarize though: automatic termination and resume are independent, but the former works better if you support the latter.

Also, the resume APIs are suited to integrating with existing mechanisms like session restore.
As I understand it (and I may be wrong) Resume will restore the last state of the application before it was quit, but automatic termination has something to do with the application (explicitly) telling OS X when it can be terminated by the operating system. However, I believe automatic termination won't apply unless the application explicitly states that it supports it.
Alex, automatic termination is significantly more complicated than that, but your general view of it is correct. The WWDC video really is the best resource, but you can think of it as decoupling the idea of "process" and "application"; in an automatic-termination-aware application you can have an app with no process, a process with no app, or the more usual combinations. This allows the system to optimize both memory usage (killing processes when the user can't tell), and relaunch time (not killing processes when memory isn't short).
Blocks: 714147
Summary: [10.7] add resume support for Mac OS X 10.7 Lion → [10.7] add resume session support for Mac OS X 10.7 Lion
I think the info.plist option in bug 967970 explicitly disabled our support for this but according to [1], Apple was forcing this result for org.mozilla.firefox already anyways.

I think we need to do something along the lines of (untested):
1) Remove NSDisablePersistence or set it to False (in order to override the org.mozilla.firefox special handling?)
2) Implement application:shouldSaveApplicationState: and/or window:setRestorable: and properly handle private windows and ensure no private window titles leak to storage [2]. We don't actually need/want to store/use any specific new state as session restore can already handle all of this in a cross-platform manner, we just need OS X to think we can restore.
3) Test that the above works for org.mozilla.firefox, not just nightly. If not, figure out how to bypass Apple's hard-coding.

[2] is a good walk-though on all of this.

[1] https://trac.torproject.org/projects/tor/ticket/8987#comment:7
[2] https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/StrategiesforImplementingYourApp/StrategiesforImplementingYourApp.html#//apple_ref/doc/uid/TP40007072-CH5-SW33
Hardware: x86 → All
What are next steps for this?

Who can check through the above documentation to test this out?
Flags: needinfo?(MattN+bmo)
André/Stephen, is this something you can take a look at? This hurts user retention since other browsers resume but not Firefox.
Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(areinald.bug)
I don't know much about the flags in the plist. But the following comes to my mind:

As far as I understand, persistence of opened windows/tabs is handled by Firefox itself and not by Mac OS X. So having the system relaunch Firefox on session opening would be enough. I can think of a few (Apple-supported) hacks to do just that.

A side note:

Some time ago I opened bug 996056. This bug was present in 10.9, and likely in 10.7 also. This bug is one reason (but obviously not the only one) why Firefox was not relaunched at session opening, as the user launchd was in charge of tracking and restoring user running processes.

In 10.11 (and maybe 10.10) Apple changed the launchd architecture so that there is no more "by user" launchd, only the "root" launchd. As a result, the current Firefox relaunch mechanism doesn't yield any longer the weirdness pointed in the mentioned bug. This also results in Firefox staying visible in Activity Monitor under "Applications in last 8 hours" mode, even after a relaunch (profile selection, update, crash etc).
Flags: needinfo?(areinald.bug)
There may also be some useful information in bug 1051979. I added both bugs in the "see also" list.
See Also: → 1051979, 996056
Flags: needinfo?(spohl.mozilla.bugs)
for investigation
Flags: needinfo?(MattN+bmo)
Priority: -- → P1
Whiteboard: [fxgrowth] → [fxgrowth], tpi:+
Priority: P1 → P2
As bug 1326181 has been marked as dup, is Lion still supported by Firefox or should the task be updated to macOS 10.10/.11?
This bug was initially filed when 10.7 was brand new, that's why it was in the summary. I've updated it.
Summary: [10.7] add resume session support for Mac OS X 10.7 Lion → Add resume session support on macOS
Thanks Markus. I would have done it, but wasn't sure about current support.
First: this ended up not working. Or I'm using a testing methods on a Debug build that would never work anyways. Unsure.

But what :MattN said about Apple hardcoding Firefox to not be started seems to be correct. I don't know how or why, but AFAICT it's something that we need to get established as fact or fiction before we continue here!
This is something I don't know how to do without a bit of help...

I'm posting this approach here for posterity and to hopefully prove useful. I didn't port over the 'launch without opening a window when configured as a hidden login item' code, which was too hairy - the `ScopedCFTypeRef` template code proved too much for me to handle at this point and in the timeframe I gave myself.

IMHO, this is a huge gap in platform integration functionality that has been allowed to exist for way to long. How can I help to get this on a roadmap?
Duplicate of this bug: 1588137

Haik, I'm needinfo'ing you because I saw you reached out to Apple in bug 1570451, but feel free to redirect if not applicable. Can we ping our contacts at Apple to verify if AppKit is really blacklisting us from starting on login as mentioned in comment #11 and the linked Tor bug [0]?

Looking at /System/Library/Frameworks/AppKit.framework/Versions/Current/AppKit on my machine running macOS Catalina 10.15.1 Beta I still see behavior that seems to match the Tor issue, specifically checking for _CFAppVersionLessThan(CFSTR("org.mozilla.firefox"), -1.0) somewhere inside _NSEnablePersistentUI.

[0] https://trac.torproject.org/projects/tor/ticket/8987#comment:7

Flags: needinfo?(haftandilian)

(In reply to Reuben Morais [:reuben] from comment #23)

Haik, I'm needinfo'ing you because I saw you reached out to Apple in bug 1570451, but feel free to redirect if not applicable. Can we ping our contacts at Apple to verify if AppKit is really blacklisting us from starting on login as mentioned in comment #11 and the linked Tor bug [0]?

Looking at /System/Library/Frameworks/AppKit.framework/Versions/Current/AppKit on my machine running macOS Catalina 10.15.1 Beta I still see behavior that seems to match the Tor issue, specifically checking for _CFAppVersionLessThan(CFSTR("org.mozilla.firefox"), -1.0) somewhere inside _NSEnablePersistentUI.

[0] https://trac.torproject.org/projects/tor/ticket/8987#comment:7

Done. I'll update the bug once I hear back.

Flags: needinfo?(haftandilian)
You need to log in before you can comment on or make changes to this bug.