Titus Stevenson Reporter
	Description • 16 years ago

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9) Gecko/2008061004 Firefox 3.0a4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9) Gecko/2008061004 Firefox 3.0a4

When restoring a session all Firefox windows are put into the currently active Space and not into the Spaces they were in.

Reproducible: Always

Steps to Reproduce:
1.Open several Firefox windows
2.Put them into different Spaces
3.Restart Firefox
Actual Results:  
All windows are in one Space

Expected Results:  
Windows are in the Spaces they were put into

	Simon Bünzli
	Comment 1 • 16 years ago

See also bug 372650 for the same request on Linux.

	Sylvain Pasche
	Comment 2 • 15 years ago

hmm, I didn't see at first that this bug was opened for Mac. So I made bug 372650 cross platform and opened a new bug for the Cocoa implementation. Sorry for all the noise.

What about making bug 372650 the cross platform implementation and bug 450953 depend on it?

Basically, bug 372650 would have the widget/public/* and widget/src/xpwidgets/* part. bug 450952 the widget/src/gtk2/* part and finally bug 450953 the widget/src/cocoa/* part.

	Jez Ng [:int3]
	Comment 5 • 13 years ago

It looks like there's no public API that makes this possible:

http://lists.apple.com/archives/quartz-dev/2009/Jul/msg00002.html

"No, there is no API to put a window on a particular space."

There seem to be undocumented ways to do it, though it's probably not the best idea to use them:

http://stackoverflow.com/questions/2308820/how-can-i-programatically-move-one-terminal-app-window-to-another-space

	Florian Bender
	Comment 6 • 9 years ago

(In reply to Jez Ng [:int3] from comment #5)
> "No, there is no API to put a window on a particular space."

This may have changed by now (and broken again?), see https://code.google.com/p/chromium/issues/detail?id=74812#c28 and following.

	Tom Ritter [:tjr] (OOTO until 4/30 at least)
	Comment 7 • 6 years ago

This is so very annoying, and frankly, makes me delay updating.

As an update, I trolled through the whole Chrome bug report history.  Some notables:

- In Aug 2015, they got a reply from Apple. Applications are not supposed to be able to re-open themselves on (correct/different) spaces. It's by design. However, windows should restore themselves to the correct location after a reboot. IF they don't, it's a bug in the application because it doesn't properly us NSDocument, encodeRestorableStateWithCoder, and restoreStateWithCoder

- In Apr 2017, people noticed that iTerm somehow figured out how to preserve the space configuration across reboots. (That's interesting, but it's not the bug; this bug is about session restore and browser restart absent a reboot, I think.)

- There's some mac documentation about that too: https://developer.apple.com/library/content/documentation/General/Conceptual/MOSXAppProgrammingGuide/CoreAppDesign/CoreAppDesign.html#//apple_ref/doc/uid/TP40010543-CH3-SW26

- There is apparently an undocumented API for moving a window to a space: CGSSpaceAddWindowsAndRemoveFromSpaces ; which would help for Session Restore. 

- There is also the (older, slightly more documented) private method CGSMoveWorkspaceWindowList

- A former Apple graphics engineer said:

> There is a high probability that future macOS releases will rename WindowServer's SPI calls for managing a window's space (the CGS* methods). (This is armchair advice from a former CoreGraphics engineer: I was on the team while we were building Mission Control.)




So, long story short, we have two options:

1: Do nothing, wait for Apple to give us the APIs.

2: Do runtime version detection of the OS, and if it's a version we know this works with, enable the feature.  Maybe also require a non-default flag to be flipped.

I don't really know who to ask if we would accept a patch to do #2. I guess I'll start with Tim, and hopefully he can redirect?

	Tim Taubert [:ttaubert] (inactive)
	Comment 8 • 6 years ago

Redirecting to Mike, he's taken over the Session Restore feature.

	Mike de Boer [:mikedeboer] Assignee
	Comment 9 • 6 years ago

I'm thinking that https://bugs.chromium.org/p/chromium/issues/detail?id=74812#c78 might something we can use here, if runtime detection is an option.

I'd prefer getting a `workspaceID` getter and a `moveToWorkspace(workspaceID)` on nsPIDOMWindow as a more generic interface for *Nix support in the future and implement it by proxying calls to nsCocoaWindow.mm for starters.

Relevant code snippet from the post I linked to:

```objc
// Grab workspace identifier:
NSObject* workspace_identifier = [self.window performSelector:@selector(_copyWorkspaceIdentifier)]

// Move a window to a workspace
NSObject* contextID = [NSApp performSelector:@selector(contextID)];
int realwindownumber = [self.window performSelector:@selector(_realWindowNumber)];
NSObject* windowID = @[@(realwindownumber)];
int spacename = CGSSpaceWithName(contextID, workspace_identifier);
CGSSpaceAddWindowsAndRemoveFromSpaces(contextID, spacename, windowID, 0x80007);
```

Is `respondsToSelector` applicable here to check if `CGSSpaceAddWindowsAndRemoveFromSpaces` is available?

	Markus Stange [:mstange]
	Comment 10 • 6 years ago

No it's not, but you can use dlsym to look up the function dynamically, similar to what we do for CGContextSetFontSmoothingBackgroundColor: https://searchfox.org/mozilla-central/rev/b7e3ec2468d42fa59d86c03ec7afeb209813f1d4/gfx/2d/CGTextDrawing.h#22-35

	Mike de Boer [:mikedeboer] Assignee
	Comment 11 • 6 years ago

This is what I managed to get to within a reasonable timeframe:

 * Add a `getWorkspaceID()` and `moveToWorkspace(workspaceID)` to the [[Window]] object, so that privileged, chrome-only scripts can do something useful.
 * Implemented the OSX Space ID retrieval is it is supposed to work, using undocumented, private APIs.
 * Set up Sessionstore to be able to work with this architecture once each widget implementation (cocoa, win, gtk, etc) gains support for it.

These private APIs were also used by iTerm2 and Chrome some time ago, but were removed because they _apparently_ stopped working. It's not documented anywhere _why_ and _how_ they stopped working, so for posterity I'll note it here.

Today, running OSX 10.13.x:
 * invoking `CGSGetWindowWorkspace()` for a window on the default Space (Desktop 1 once you added another Space), will return '1'. As expected.
 * invoking `CGSGetWindowWorkspace()` for a window on any other Space than the default one (Desktop X, where x is not '1'), will return '0'. In other words: totally useless, garbage.
 * invoking `CGSMoveWorkspaceWindowList()` and passing in '2' (interpolated ID) as the Space number, does not move a window to that Space (i.e. 'Desktop 2'). Also utterly useless.
 * invoking `CGSMoveWorkspaceWindowList()` and passing in '1' as the Space number, does not move a window to that Space (i.e. 'Desktop 1'). The window to move resides in another space, like 'Desktop 3'.

The - private, granted - APIs are there and can be invoked but do not work as expected. And I doubt they will in the near future.

This will make it very _very_ unlikely that Firefox will have support for multiple Spaces some day, because Apple will need to create and ship an API that is
a) public,
b) future-proof (i.e. won't break between releases).

To be clear: I could live with using a private APIs like I tried to do in this patch, but they need to work. If Apple can distribute a fixed-up CoreGraphics bundle update, I'd be over the moon.
Not only Firefox would benefit here; Chrome, iTerm2 and many other productivity apps - that coincidentally will never fit in the App Store model - will too, accounting for a reach of millions of users worldwide.

I'd love to get in touch with an Apple spokesperson to explain more and/ or request a feature in more detail!

	Pulsebot
	Comment 20 • 4 years ago

Pushed by mdeboer@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c32706293416
Add support for Mac OSX spaces in session restore, which allows any window to be restored to their respective (work)space. r=mconley,mstange,nika