Open
Bug 394768
Opened 17 years ago
Updated 2 years ago
XUL apps do not act on stored window position when starting up
Categories
(Core :: XUL, defect)
Tracking
()
NEW
People
(Reporter: db48x, Unassigned)
References
Details
Attachments
(1 file, 2 obsolete files)
1.26 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•17 years ago
|
||
Attachment #279473 -
Flags: review?
Reporter | ||
Updated•17 years ago
|
Attachment #279473 -
Flags: review? → review?(mano)
Reporter | ||
Comment 2•17 years ago
|
||
oops, that patch had an unrelated change in it.
Attachment #279473 -
Attachment is obsolete: true
Attachment #279476 -
Flags: review?(mconnor)
Attachment #279473 -
Flags: review?(mano)
Reporter | ||
Updated•17 years ago
|
Attachment #279476 -
Flags: review?(mconnor)
Reporter | ||
Comment 3•17 years ago
|
||
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
Reporter | ||
Comment 4•17 years ago
|
||
Attachment #279476 -
Attachment is obsolete: true
Attachment #279577 -
Flags: review?
Reporter | ||
Updated•17 years ago
|
Attachment #279577 -
Flags: review? → review?(gavin.sharp)
Comment 5•17 years ago
|
||
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)
Updated•17 years ago
|
QA Contact: general → xptoolkit.xul
Reporter | ||
Comment 6•17 years ago
|
||
well, we can ask :)
cc'ing bz and dbaron to ask their opinions on this patch
Comment 7•17 years ago
|
||
Um... you mean people use window managers that don't do smart placement into empty areas of the screen? Why???
Reporter | ||
Comment 8•17 years ago
|
||
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•17 years ago
|
||
So wouldn't this patch override its smart placement behavior?
Reporter | ||
Comment 10•17 years ago
|
||
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•17 years ago
|
||
> 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.
Reporter | ||
Comment 12•17 years ago
|
||
What WM do you use, and how does it work?
Comment 13•17 years ago
|
||
I use AfterStep. I have it set to place in empty space if available and ask me otherwise.
Comment 14•17 years ago
|
||
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
See Also: → https://launchpad.net/bugs/204480
Comment 17•13 years ago
|
||
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•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: db48x → nobody
Status: ASSIGNED → NEW
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•