The result is that the window is sized correctly, but positioned at 0,0. (actual results may vary depending on your WM) The solution is simple, I'll attach a patch.
Created attachment 279473 [details] [diff] [review] 394768-1.diff
Attachment #279473 - Flags: review?
Attachment #279473 - Flags: review? → review?(mano)
Created attachment 279476 [details] [diff] [review] 394768-2.diff oops, that patch had an unrelated change in it.
Ok, so it turns out that this is actually a Linux-specific problem. 7 years ago it was decided that it was better to rely on the window manager to remember and act on the last window position in spite of the problems that causes. These days it seems that relatively few window managers try to do this, though there are undoubtedly some that still do. Also, at some point in the last seven years we started restoring the window size again, overriding the window manager's decision. I say we override the WM's choice of position as well. I'll attach a patch for that.
Status: NEW → ASSIGNED
Component: General → XP Toolkit/Widgets: XUL
OS: All → Linux
Product: Firefox → Core
Summary: Firefox does not act on stored window position when starting up → XUL apps do not act on stored window position when starting up
Created attachment 279577 [details] [diff] [review] 394768-3.diff
Attachment #279577 - Flags: review? → review?(gavin.sharp)
Comment on attachment 279577 [details] [diff] [review] 394768-3.diff I don't think I'm the right person to make the call on this. I'm not sure who is... Perhaps bz/dbaron have an opinion?
Attachment #279577 - Flags: review?(gavin.sharp)
well, we can ask :) cc'ing bz and dbaron to ask their opinions on this patch
Um... you mean people use window managers that don't do smart placement into empty areas of the screen? Why???
The default window manager for Fedora/Red Hat (metacity) does smart placement, but it doesn't remember the last window placement for use when there is no empty space (when there are maximized windows, for example.) I know it would be nice if window managers worked well in this regard, but in my history of using linux the only one that ever did was ratpoison, and it uses only tiling.
So wouldn't this patch override its smart placement behavior?
Oh, certainly. I wouldn't mind finding a way to determine if the WM is going to do something intelligent, but I don't know if that's possible. The way it works right now just isn't very useful. In my spare time I'm working on a xulrunner app where several copies of the app can communicate with each other over the network. Testing the app naturally requires running more than one copy of it, and having them both come up on the screen overlapping each other makes testing them more annoying than it has to be. (So does minimizing everything before I run the apps, of course.) Looking in to a way to fix that led me to notice that Firefox has the same problem, and thus to creating this bug.
> The way it works right now just isn't very useful. Perhaps with your WM and in your usecases... I'm pretty happy with the way my windows get placed, and wouldn't want the app to override the WM's decisions on it.
What WM do you use, and how does it work?
I use AfterStep. I have it set to place in empty space if available and ask me otherwise.
I was tempted to use the same patch for bug 410337 but now that I discovered this bug I see it may not be the best option.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
I'm hoping this bug is still getting some attention. It's been a while since the bug was last updated. Based on my readings, my best guess is that with different WM's and usage patterns, people may want different behaviours. I use Fedora16-FXCE4.8(firefox 9.0); it's a small annoyance that FF doesn't remember. It looks like the window position is getting written into localstore.rdf. It's just not getting used when it first startup. I wonder if this can be a configurable variable, like localstore.use_saved_startup_position=true, that can be set by the user, and subsequently be used to determine the behaviour? Thx.
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: ASSIGNED → RESOLVED
Last Resolved: 23 hours ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.