394768 - XUL apps do not act on stored window position when starting up

Status: NEW

(Core :: XUL, defect)

Description

[Daniel Brooks [:db48x]]

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.

Comment 1

[Daniel Brooks [:db48x]]

Attachment: 394768-1.diff

Comment 2

[Daniel Brooks [:db48x]]

Attachment: 394768-2.diff

oops, that patch had an unrelated change in it.

Comment 3

[Daniel Brooks [:db48x]]

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.

Comment 4

[Daniel Brooks [:db48x]]

Attachment: 394768-3.diff

Comment 5

[:Gavin Sharp [email: [e-mail]]]

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?

Comment 6

[Daniel Brooks [:db48x]]

well, we can ask :)

cc'ing bz and dbaron to ask their opinions on this patch

Comment 7

[Boris Zbarsky [:bzbarsky]]

Um... you mean people use window managers that don't do smart placement into empty areas of the screen?  Why???

Comment 8

[Daniel Brooks [:db48x]]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

So wouldn't this patch override its smart placement behavior?

Comment 10

[Daniel Brooks [:db48x]]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 12

[Daniel Brooks [:db48x]]

What WM do you use, and how does it work?

Comment 13

[Boris Zbarsky [:bzbarsky]]

I use AfterStep.  I have it set to place in empty space if available and ask me otherwise.

Comment 14

[Sylvain Pasche]

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.

Comment 17

[ccchen]

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.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.