Window position in virtual desktop not restored across browser sessions on MS Windows
Categories
(Firefox :: Session Restore, defect, P2)
Tracking
()
People
(Reporter: report0, Assigned: mikedeboer, NeedInfo)
References
(Regressed 1 open bug)
Details
(Keywords: platform-parity, regression)
Attachments
(4 files)
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release) Build ID: 20130618035212 Steps to reproduce: - Open a virtual desktop manager (in my case Litestep, WinXP) - Open multiple Firefox windows in different desktops - Exit Firefox, then restart Actual results: Firefox windows on all non-focused desktops will be moved to the current focused desktop, with positions cropped to the nearest screen edge. It seems that Firefox is attempting to prevent any windows being created offscreen during startup, but needs to be disabled to prevent conflicts with VWMs in Windows. Expected results: Windows should have opened in the respective relative virtual desktop positions, like versions 21 and before.
![]() |
||
Updated•11 years ago
|
Needs to be CONFIRMED. Hope it gets fixed. Personal choice of sticking with older version for now.
The problem is that my original submission of this bug was in reference to the general Firefox handling of window borders for all Windows platforms - see https://support.mozilla.org/en-US/questions/962982#answer-452667 After that an admin read my anecdote and decided to relabel it is a LiteStep/XP specific bug, when it clearly is not just that. It just a way of sweeping it under the carpet. This bug should probably be resubmitted by someone.
After upgrading from firefox 17 to firefox 24, the window position is no more remembered across sessions. I tried to remove localstore.rdf without luck and the stored screenX/Y values are correct. The window height and width are instead remembered correctly. User agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20140207 Firefox/24.0 Iceweasel/24.3.0
(In reply to Trek from comment #3) > After upgrading from firefox 17 to firefox 24, the window position is no > more remembered across sessions. I tried to remove localstore.rdf without > luck and the stored screenX/Y values are correct. The window height and > width are instead remembered correctly. > > User agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20140207 > Firefox/24.0 Iceweasel/24.3.0 https://bugzilla.mozilla.org/show_bug.cgi?id=864107 It was a bug that got fixed. I don't believe firefox was implemented with a setting to reverse the bug so I myself had found a solution. I use palemoon browser which a option was implemented to reverse this bug. Name of the setting in about:config browser.sessionstore.exactPos to true. More detailed info. http://forum.palemoon.org/viewtopic.php?p=19756#p19756 http://forum.palemoon.org/viewtopic.php?f=24&t=3357
Devs, it would be greatly appreciate it if you could add a config option similar to that implemented in Palemoon.
Comment 6•10 years ago
|
||
Can you reproduce the problem on the latest nightly ? http://nightly.mozilla.org/
Thanks for your response. Yes, I can confirm 30.0a1 still snaps all browser windows to the relative desktop resolution. There is still no upgrade path from 17.0 for users with this issue.
To clarify: 17.0 and previous would not always exactly restore sessions in identical VWM desktops, partly since FF cannot know how different VWM coordinate implementations. But that is a problem for the VWM user to deal with, since they will usually be able to perform a 'gather all windows' and at least have the relative positioning correctly restored. After 17, both absolute and relative positioning are disrupted due to nearest desktop edge cropping. VWM and other users at least require a config option to revert back to the 17.0 behaviour.
Updated•10 years ago
|
Comment 10•10 years ago
|
||
Since the bug is still present in the (just released) 29.0 : Is there any progress on this ? It's really annoying shuffling around >50 browser windows on a daily basis.
Reporter | ||
Comment 11•10 years ago
|
||
Admins, kindly confirm this behaviour. Users with this problem would like to upgrade from FF21.
Updated•10 years ago
|
Comment 12•10 years ago
|
||
What is the clean way forward to get rid of the platform restriction to "x86 Windows XP" and the restrictions to windows and litestep in the bug name ? This bug is obviously crossplatform and does not depend on litestep as window manager. Linux / vtwm here, btw. And as a help for bug analysis : I see the browser windows placed on the correct (off screen) positions on the virtual desktop, and then finally all moved to the on screen part of the virtual desktop.
Updated•10 years ago
|
Comment 13•10 years ago
|
||
Thanks. Getting closer :) Since I actually see the windows at start up being restored to their correct position, and they are moved to the visual part of the desktop just before the window content starts loading, I'd guess the positions _are_ stored correctly across sessions, but they are overwritten later on. Very likely (as pointed out by my predecessors) by the code introduced as fix for https://bugzilla.mozilla.org/show_bug.cgi?id=864107 Since there are contradicting targets (restoring windows to visible screen in 864107 and keeping the original positions in a virtual desktop manager), probably the best way is indeed adding another configuration variable (defaulted to the 864107 behaviour).
Comment 14•10 years ago
|
||
Yeah, I'm pretty sure this is caused by bug 864107.
Comment 15•10 years ago
|
||
Still present in 30.0.
Comment 16•10 years ago
|
||
Still present, still annoying in 31.0.
Comment 17•9 years ago
|
||
Still present in 32.* and 33.0. I guess the version tag (still pointing to the 30 Branch) needs to be updated. Is there sth. like a sticky tag ? Just a side note : This probably will gain importance with MS Windows 10 supporting multiple desktops. And another sidenote : I'm tempted writing a fix. However I need some advise, whether another configuration variable is the way to go, or autodetection. IMHO this is a worthy candidate for a configuration variable (although I also see that lots of configs are QA's nightmare). I have no clue about how to do autodetection, either.
Reporter | ||
Comment 18•9 years ago
|
||
A fix would be most welcome. I might recommend following the same about:config variable convention used in Palemoon for now. I'm not sure how this could be generally autodetected to make it worthwhile.
Updated•9 years ago
|
Comment 20•9 years ago
|
||
The issue in (In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #19) > > *** This bug has been marked as a duplicate of bug 372650 *** Please note that the analysis of the problem is more evolved in this bug record. Following 372650 only, the knowledge is lost that the original problem was already fixed (at least in general), but clearly reintroduced by the code change for 864107.
Reporter | ||
Comment 21•9 years ago
|
||
As Wirtz says, it is a different bug from a more recent code change than 372650.
Updated•8 years ago
|
Comment hidden (obsolete) |
Comment 23•4 years ago
|
||
This was just fixed for Linux and Mac.
Comment 24•4 years ago
|
||
For developers:
In widget/windows/nsWindow.cpp
, implement functions:
int32_t nsWindow::GetWorkspaceID();
void nsWindow::MoveToWorkspace(int32_t workspaceID);
See:
Updated•4 years ago
|
Comment 25•4 years ago
|
||
(In reply to Ben Bucksch (:BenB) from comment #24)
In
widget/windows/nsWindow.cpp
, implement functions:
int32_t nsWindow::GetWorkspaceID();
void nsWindow::MoveToWorkspace(int32_t workspaceID);
IVirtualDesktopManager::GetWindowDesktopId
and IVirtualDesktopManager::MoveWindowToDesktop
would be usable to implement them.
https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ivirtualdesktopmanager
But int32_t
is insufficient to hold Guid
(128-bit).
Assignee | ||
Comment 26•4 years ago
•
|
||
(In reply to Masatoshi Kimura [:emk] from comment #25)
(In reply to Ben Bucksch (:BenB) from comment #24)
In
widget/windows/nsWindow.cpp
, implement functions:
int32_t nsWindow::GetWorkspaceID();
void nsWindow::MoveToWorkspace(int32_t workspaceID);
IVirtualDesktopManager::GetWindowDesktopId
andIVirtualDesktopManager::MoveWindowToDesktop
would be usable to implement them.
https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ivirtualdesktopmanagerBut
int32_t
is insufficient to holdGuid
(128-bit).
Yeah, I'm looking into this too, but it indeed requires switching to strings to support the Windows style. Right now my patches look like:
void nsWindow::GetWorkspaceID(nsAString& workspaceID);
void nsWindow::MoveToWorkspace(const nsAString& workspaceID);
And I've changed the Linux & OSX code to convert the string to int's first, which seemed like the least messy solution.
But why MS needed to over-engineer this thing into using Guids is beyond me. Oh well.
Comment 27•4 years ago
|
||
Thanx for working on this, and sorry for being obnoxious, but:
IMHO the bug report describes two related, but separate problems:
a) The workspace ID of a window is not preserved across session restores.
b) After session restore, all windows are pulled into the current viewport of the workspace (so in effect the window positions are not preserved across session restores).
AFAICS the code fixes a) but not b).
So this is a partial (though highly appreciated) fix only.
Just to make sure the virtual desktop concept is understood: In some virtual desktop managers (window managers) desktop extensions may be much larger than the part being displayed (similar to painting programs, in which you can zoom in to display parts of the canvas only). The arrangement of firefox windows on that large (virtual) desktop is exactly what is lost in b).
Assignee | ||
Comment 28•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 29•4 years ago
|
||
Depends on D67822
Assignee | ||
Comment 30•4 years ago
|
||
Depends on D67823
Assignee | ||
Comment 31•4 years ago
|
||
Depends on D67824
Comment 32•4 years ago
|
||
Mike, you didn't specify reviewers correctly, phabricator sets them as empty. Do you want me to review the patch or are you going to do other changes there?
Assignee | ||
Comment 33•4 years ago
|
||
Yeah, that was all intentional, sorry for not mentioning that explicitly! This is a set of WIP patches that I intend to submit for review whenever I get the chance to make them compile and work on all platforms. That's quite an essential bit right there 😉
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 34•4 years ago
|
||
Pushed by mdeboer@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/08359730557d Part 1 - Change Window widget base classes to return and use strings for workspace IDs, rather than integers. r=nika https://hg.mozilla.org/integration/autoland/rev/cd850f6d0b0b Part 2 - Convert the OSX Spaces handling to accept string-type workspace IDs. r=mstange,nika https://hg.mozilla.org/integration/autoland/rev/eceeef4fc062 Part 3 - Convert the Linux virtual desktop handling to accept string-type workspace IDs. r=stransky,nika https://hg.mozilla.org/integration/autoland/rev/1c8115a9a684 Part 4 - Implement virtual desktop switching for Windows 10 and above. r=mhowell,emk
Comment 35•4 years ago
|
||
Backed out 4 changesets (bug 890125) for Windows MinGW build bustages tier2 failures.
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=296172494&repo=autoland&lineNumber=94867
Backout: https://hg.mozilla.org/integration/autoland/rev/449fd8a4035ec5f19127f2d042c6ee6d7b6bf740
Comment 36•4 years ago
|
||
Pushed by mdeboer@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6e71761c1018 Part 1 - Change Window widget base classes to return and use strings for workspace IDs, rather than integers. r=nika https://hg.mozilla.org/integration/autoland/rev/17b15e227d3b Part 2 - Convert the OSX Spaces handling to accept string-type workspace IDs. r=mstange,nika https://hg.mozilla.org/integration/autoland/rev/6e2c1facb7e0 Part 3 - Convert the Linux virtual desktop handling to accept string-type workspace IDs. r=stransky,nika https://hg.mozilla.org/integration/autoland/rev/68475f12d4f1 Part 4 - Implement virtual desktop switching for Windows 10 and above. r=mhowell,emk
Comment 37•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6e71761c1018
https://hg.mozilla.org/mozilla-central/rev/17b15e227d3b
https://hg.mozilla.org/mozilla-central/rev/6e2c1facb7e0
https://hg.mozilla.org/mozilla-central/rev/68475f12d4f1
Comment 38•4 years ago
|
||
Backed out 4 changesets (bug 890125) for central bustages complaining about nsWindow.cpp
Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=004536f666bfc2acf7002da703f003216f8aa5a5&searchStr=build&selectedJob=296503420
Backout link: https://hg.mozilla.org/integration/autoland/rev/d8da923e24edc189f72b44945065818aef2090cb
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=296503420&repo=mozilla-central&lineNumber=43317
[task 2020-04-06T22:10:47.219Z] 22:10:47 INFO - make[4]: Leaving directory '/builds/worker/workspace/obj-build/layout/forms'
[task 2020-04-06T22:10:51.363Z] 22:10:51 INFO - make[4]: Entering directory '/builds/worker/workspace/obj-build/widget/gtk'
[task 2020-04-06T22:10:51.368Z] 22:10:51 INFO - /builds/worker/fetches/sccache/sccache /builds/worker/fetches/clang/bin/clang++ -std=gnu++17 -m32 -o nsWindow.o -c -I/builds/worker/workspace/obj-build/dist/stl_wrappers -I/builds/worker/workspace/obj-build/dist/system_wrappers -include /builds/worker/checkouts/gecko/config/gcc_hidden.h -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -DDEBUG=1 -DOS_POSIX=1 -DOS_LINUX=1 -DCAIRO_GFX '-DMOZ_APP_NAME="firefox"' -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DSTATIC_EXPORTABLE_JS_API -I/builds/worker/checkouts/gecko/widget/gtk -I/builds/worker/workspace/obj-build/widget/gtk -I/builds/worker/workspace/obj-build/ipc/ipdl/_ipdlheaders -I/builds/worker/checkouts/gecko/ipc/chromium/src -I/builds/worker/checkouts/gecko/ipc/glue -I/builds/worker/checkouts/gecko/layout/base -I/builds/worker/checkouts/gecko/layout/generic -I/builds/worker/checkouts/gecko/layout/xul -I/builds/worker/checkouts/gecko/other-licenses/atk-1.0 -I/builds/worker/checkouts/gecko/widget -I/builds/worker/checkouts/gecko/widget/headless -I/builds/worker/checkouts/gecko/widget/x11 -I/builds/worker/workspace/obj-build/dist/include -I/builds/worker/workspace/obj-build/dist/include/nspr -I/builds/worker/workspace/obj-build/dist/include/nss -fPIC -DMOZILLA_CLIENT -include /builds/worker/workspace/obj-build/mozilla-config.h -Qunused-arguments -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wempty-init-stmt -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wc++2a-compat -Wcomma -Wimplicit-fallthrough -Wunused-function -Wunused-variable -Werror=non-literal-null-conversion -Wstring-conversion -Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wno-error=tautological-type-limit-compare -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=backend-plugin -Wno-error=return-std-move -Wno-error=atomic-alignment -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-unknown-warning-option -D_GLIBCXX_USE_CXX11_ABI=0 -fno-sized-deallocation -fno-aligned-new -fcrash-diagnostics-dir=/builds/worker/artifacts -march=pentium-m -msse -msse2 -mfpmath=sse -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -Xclang -load -Xclang /builds/worker/workspace/obj-build/build/clang-plugin/libclang-plugin.so -Xclang -add-plugin -Xclang moz-check -Os -fno-omit-frame-pointer -funwind-tables -Werror -I/builds/worker/checkouts/gecko/widget/gtk/compat-gtk3 -pthread -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/gtk-3.0/unix-print -pthread -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/libdrm -I/usr/include/dbus-1.0 -I/usr/lib/i386-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -Wno-error=shadow -fexperimental-new-pass-manager -MD -MP -MF .deps/nsWindow.o.pp /builds/worker/checkouts/gecko/widget/gtk/nsWindow.cpp
[task 2020-04-06T22:10:51.369Z] 22:10:51 ERROR - /builds/worker/checkouts/gecko/widget/gtk/nsWindow.cpp:1630:15: error: call to member function 'AppendInt' is ambiguous
[task 2020-04-06T22:10:51.369Z] 22:10:51 INFO - workspaceID.AppendInt(wm_desktop[0]);
[task 2020-04-06T22:10:51.369Z] 22:10:51 INFO - ~~~~~~~~~~~~^~~~~~~~~
[task 2020-04-06T22:10:51.369Z] 22:10:51 INFO - /builds/worker/workspace/obj-build/dist/include/nsTSubstring.h:652:8: note: candidate function
[task 2020-04-06T22:10:51.369Z] 22:10:51 INFO - void AppendInt(int32_t aInteger) { AppendIntDec(aInteger); }
[task 2020-04-06T22:10:51.369Z] 22:10:51 INFO - ^
[task 2020-04-06T22:10:51.369Z] 22:10:51 INFO - /builds/worker/workspace/obj-build/dist/include/nsTSubstring.h:662:8: note: candidate function
[task 2020-04-06T22:10:51.369Z] 22:10:51 INFO - void AppendInt(uint32_t aInteger) { AppendIntDec(aInteger); }
[task 2020-04-06T22:10:51.369Z] 22:10:51 INFO - ^
[task 2020-04-06T22:10:51.370Z] 22:10:51 INFO - /builds/worker/workspace/obj-build/dist/include/nsTSubstring.h:672:8: note: candidate function
[task 2020-04-06T22:10:51.370Z] 22:10:51 INFO - void AppendInt(int64_t aInteger) { AppendIntDec(aInteger); }
[task 2020-04-06T22:10:51.371Z] 22:10:51 INFO - ^
[task 2020-04-06T22:10:51.371Z] 22:10:51 INFO - /builds/worker/workspace/obj-build/dist/include/nsTSubstring.h:682:8: note: candidate function
[task 2020-04-06T22:10:51.371Z] 22:10:51 INFO - void AppendInt(uint64_t aInteger) { AppendIntDec(aInteger); }
[task 2020-04-06T22:10:51.371Z] 22:10:51 INFO - ^
[task 2020-04-06T22:10:51.371Z] 22:10:51 INFO - /builds/worker/workspace/obj-build/dist/include/nsTSubstring.h:653:8: note: candidate function not viable: requires 2 arguments, but 1 was provided
[task 2020-04-06T22:10:51.371Z] 22:10:51 INFO - void AppendInt(int32_t aInteger, int aRadix) {
[task 2020-04-06T22:10:51.371Z] 22:10:51 INFO - ^
[task 2020-04-06T22:10:51.371Z] 22:10:51 INFO - /builds/worker/workspace/obj-build/dist/include/nsTSubstring.h:663:8: note: candidate function not viable: requires 2 arguments, but 1 was provided
[task 2020-04-06T22:10:51.371Z] 22:10:51 INFO - void AppendInt(uint32_t aInteger, int aRadix) {
[task 2020-04-06T22:10:51.371Z] 22:10:51 INFO - ^
[task 2020-04-06T22:10:51.371Z] 22:10:51 INFO - /builds/worker/workspace/obj-build/dist/include/nsTSubstring.h:673:8: note: candidate function not viable: requires 2 arguments, but 1 was provided
[task 2020-04-06T22:10:51.372Z] 22:10:51 INFO - void AppendInt(int64_t aInteger, int aRadix) {
[task 2020-04-06T22:10:51.372Z] 22:10:51 INFO - ^
[task 2020-04-06T22:10:51.372Z] 22:10:51 INFO - /builds/worker/workspace/obj-build/dist/include/nsTSubstring.h:683:8: note: candidate function not viable: requires 2 arguments, but 1 was provided
[task 2020-04-06T22:10:51.372Z] 22:10:51 INFO - void AppendInt(uint64_t aInteger, int aRadix) {
[task 2020-04-06T22:10:51.372Z] 22:10:51 INFO - ^
[task 2020-04-06T22:10:51.372Z] 22:10:51 INFO - 1 error generated.
[task 2020-04-06T22:10:51.372Z] 22:10:51 INFO - /builds/worker/checkouts/gecko/config/rules.mk:750: recipe for target 'nsWindow.o' failed
[task 2020-04-06T22:10:51.372Z] 22:10:51 ERROR - make[4]: *** [nsWindow.o] Error 1
[task 2020-04-06T22:10:51.372Z] 22:10:51 INFO - make[4]: Leaving directory '/builds/worker/workspace/obj-build/widget/gtk'
[task 2020-04-06T22:10:51.372Z] 22:10:51 INFO - /builds/worker/checkouts/gecko/config/recurse.mk:74: recipe for target 'widget/gtk/target-objects' failed
[task 2020-04-06T22:10:51.372Z] 22:10:51 ERROR - make[3]: *** [widget/gtk/target-objects] Error 2
![]() |
||
Comment 39•4 years ago
|
||
The bustage affected only Linux 32-bit.
Backout merged: https://hg.mozilla.org/mozilla-central/rev/d8da923e24ed
Comment 40•4 years ago
|
||
Pushed by mdeboer@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/bd936bfc3a0f Part 1 - Change Window widget base classes to return and use strings for workspace IDs, rather than integers. r=nika https://hg.mozilla.org/integration/autoland/rev/36e331c78398 Part 2 - Convert the OSX Spaces handling to accept string-type workspace IDs. r=mstange,nika https://hg.mozilla.org/integration/autoland/rev/70b5f44adb00 Part 3 - Convert the Linux virtual desktop handling to accept string-type workspace IDs. r=stransky,nika https://hg.mozilla.org/integration/autoland/rev/8d31ce849dfb Part 4 - Implement virtual desktop switching for Windows 10 and above. r=mhowell,emk
Comment 41•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/bd936bfc3a0f
https://hg.mozilla.org/mozilla-central/rev/36e331c78398
https://hg.mozilla.org/mozilla-central/rev/70b5f44adb00
https://hg.mozilla.org/mozilla-central/rev/8d31ce849dfb
Updated•4 years ago
|
Updated•4 years ago
|
Comment 43•4 years ago
|
||
Is this supposed to have landed yet? I'm on Dev Edition 79.0b2 (64-bit), use Windows' built-in virtual desktops, and I still have to shunt my windows to the correct desktop every time I open Firefox.
Comment 44•4 years ago
|
||
Does not work for me either with regular Windows virtual desktops: All Firefox windows opn up on the first virtual desktop after restart (Windows 10 1909 64-bit, Firefox 78.0.1)
Comment 45•3 years ago
|
||
A pref, maybe?
Comment 46•3 years ago
|
||
It says fixed in Firefox 77, but it's not quite fixed yet (actually, not at all).
- Browser windows on a VD other than 1 will always start at VD 1.
- A maximized secondary browser window on a secondary monitor that is minimized, when the browser restarts, will start "restored" (meaning neither maximized nor minimized).
Comment 47•3 years ago
|
||
I can't believe this is still an issue, I'm tired of having to move all Firefox windows to each virtual desktop each time I restart my PC
Comment 48•3 years ago
|
||
Yeah this is 100% not fixed.
Updated•3 years ago
|
Comment 49•3 years ago
|
||
This bug is closed. Further issues should be tracked in bug 1643936 instead.
Description
•