Here's my setup:

[-------- 1920 x 1080 -------]
[---- external monitor -----] [------ 1440 x 900 ------]
[-------- (space 1) ----------] [---laptop (space 2) ---]
[-----------------------------] [-------------------------]

I mostly use Firefox as a single window, maximized, the external monitor (space 1).
So screenX = 0, width = 1920.

When I restart Firefox (no auto session restore), it remembers my screenX as being 1920 (which appears to be a bug in itself), and places my window "correctly" (maximized) on the space 2.
Then if I click on History -> Restore Previous Session, it brings back my window to space 1, but keeps the screenX of 1920, so the window is totally out of view and can't be reached. I can only save it by going to the browser console and changing the screenX. Restarting doesn't help.
Note that these steps can be skipped if I'm restarting for an update, which automatically triggers session restore.

In summary:
1 - Maximize Firefox on first space
2 - Quit Firefox and open it again
3 - It is placed on the second window
4 - Click to restore session
5 - Window is positioned out of view on space 1

(Steps 3 and 4 can be skipped if session is auto restored, for example by an update)

(In reply to :Felipe Gomes (needinfo for replies!) from comment #0)

Here's my setup:

[-------- 1920 x 1080 -------]
[---- external monitor -----] [------ 1440 x 900 ------]
[-------- (space 1) ----------] [---laptop (space 2) ---]
[-----------------------------] [-------------------------]

I mostly use Firefox as a single window, maximized, the external monitor (space 1).
So screenX = 0, width = 1920.

When I restart Firefox (no auto session restore), it remembers my screenX as being 1920 (which appears to be a bug in itself), and places my window "correctly" (maximized) on the space 2.

screenX as 1920?? That sounds horrible. So during runtime, I guess the screenX property is also reported as 1920?
In that case I need to take a look at the nsCocoaWindow.mm implementation and talk with Cocoa devs to figure this thing out.
It might be that this is going to escalate into me having to implement multiple display support on all platforms as well.

It's probably not completely inaccessible. In OS display managers with shortcuts to maximize minimize windows as well as move the windows to the left and right, quarters, etc. of the screen you'd probably be able to quickly move the window back to a current machine (not exactly user friendly as if you don't know about these shortcuts it would seem like Firefox is completely unrecoverable.)

When the browser is running, screenX is correctly reported as 0. I don't know for a fact that it is getting stored as 1920 on exit... Maybe it is getting stored as 0, but on the wrong display, and when SS tries to restore to the original space, it does some wrong calculation?

(In reply to richard from comment #2)

It's probably not completely inaccessible. In OS display managers with shortcuts to maximize minimize windows as well as move the windows to the left and right, quarters, etc. of the screen you'd probably be able to quickly move the window back to a current machine (not exactly user friendly as if you don't know about these shortcuts it would seem like Firefox is completely unrecoverable.)

I don't know if macOS has this... A quick googling didn't find anything built-in to maximize that I could use... There were just suggestions on what to change in System Preferences to do that.

One thing to mention is that if I trigger Mission Control (former "Exposé") I can see the window just fine... But if I click on it, it happily goes back to out of screen again

Ok, I found more info and exact STR. It involves opening a private browsing on the second display. I will refer to display 1 and 2 as in the bug description:

1- Have a maximized Firefox window on display 1 (space 1)
2- Open a private browsing window
3- Move PB window to display 2 (space 2), and maximize it
4- Quit the browser and reopen
5- Click "Restore Previous Session"

After step 4, the fresh new browser window (no SS yet) will have opened as maximized but on the second display (remember that it was originally on display 1)

Here's the data I had on xulStore just before clicking on 5:

height: 877
screenX: 1969
screenY: 203
sizemode: maximized
width: 1920

So I guess what happens is that the fresh window initially created got restored to the previous PB window values. When SS restore kicks in it reuses the window to reposition it to the right workspace, but doesn't check if the dimensions are correct (or trigger a new maximize in case the sizemode is maximized).

Anyways, sounds like AppWindow::SavePersistentAttributes() should not be persisting PB data

(In reply to :Felipe Gomes (needinfo for replies!) from comment #3)

(In reply to richard from comment #2)

It's probably not completely inaccessible. In OS display managers with shortcuts to maximize minimize windows as well as move the windows to the left and right, quarters, etc. of the screen you'd probably be able to quickly move the window back to a current machine (not exactly user friendly as if you don't know about these shortcuts it would seem like Firefox is completely unrecoverable.)

I don't know if macOS has this... A quick googling didn't find anything built-in to maximize that I could use... There were just suggestions on what to change in System Preferences to do that.

One thing to mention is that if I trigger Mission Control (former "Exposé") I can see the window just fine... But if I click on it, it happily goes back to out of screen again

This is yet another good reason why not to use a MacOS system. You're doing good work though on tracking this down.

As Mike says this may need on all systems to ensure that Firefox doesn't restore offscreen on any platform (although there are other bugs open where people want Firefox to restore in the same place on the same workspaces as before a crash/close - in fact on Gnome when I reopen FF it doens't restore to it's half screen position that I always have it, but to a smaller section of the same half of the screen.)

Felipe, can you try the build over at https://treeherder.mozilla.org/#/jobs?repo=try&revision=56f2418288c83adb5a2170d0fcbee58ce1f882e2 that I made for you? I moved the part that restores the Space of a window to happen before its other features are restored, which will probably help and make it faster to move to the right position.

Please let me know if that helps at all, thanks!

I tested this build and I can still repro it on a fresh profile following the steps from comment 4. The very first time it didn't repro, but I was able to repro it consinstently after the 2nd try.

Hi Mike, as you are appearently working on this: do you want to assign yourself here?

[Tracking Requested - why for this release]: I've hit this myself a few times in the last week. We should consider tracking this as it makes the browser basically unusable as you can't see any window.

We can track this, but it's already getting late in the cycle to fix this for 76, let alone 75. Any fix is going to have to come soon to make it into 76 before next week's RC.

I'll implement a stop-gap solution to not support restoring to Spaces when the display count > 1; i.e. when a second, external monitor is attached, we stop trying to restore windows to their original Space.

I'll need time to find a good fix for this issue, as well as more information: how many configuration options are there for Spaces when one or more external monitors are attached?

Oooh, there's https://developer.apple.com/documentation/appkit/nsscreen/1388365-screenshaveseparatespaces, for one...

Hi Markus - my previous patch was disabling things way too eagerly, so I posted an update. Could you take a look at it again, perhaps?

Done, sorry I missed this

https://hg.mozilla.org/mozilla-central/rev/f44bb30dd8a2

I've tried to reproduce this using an old Nightly from 2020-04-17 with a MacBook air 11inch and a FullHD external screen but unfortunately I couldn't, Firefox always opens on the screen where the normal window was left after quitting. Felipe could you be so kind and verify that this is fixed using Firefox beta 77.0b9 on your end?

I can no longer reproduce this bug since this fix landed (I tested it right when it landed but forgot to mention it back here)

Hi Bogdan!
According to the comment # 20, is it okay for you if I change the Flag "firefox77" to Verified?

(In reply to Marcela from comment #21)

Hi Bogdan!
According to the comment # 20, is it okay for you if I change the Flag "firefox77" to Verified?

Yes, sorry I forgot to follow up on this one, feel free to change 77 to verified and remove qe-verify+. Thanks Marcela.

I'll change flags according to comment # 20 and comment # 22.
Please feel free to reopen it if you are still experiencing this in the latest version of Firefox.