Ubuntu

Window position is not remembered between starts

Reported by André on 2008-03-21
30
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
In Progress
Medium
firefox (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: firefox-3.0

Firefox forgets the location of the main window each time I close it down and start it back up. I have investigated this, and it turns out that Firefox rewrites parts of the localstore.rdf file in my profile, and thus changes the screenX="499" setting to screenX="0" as can be seen in the below diff.

Steps to reproduct:
1) Start firefox and move the main window until it touches the right edge of the screen.
2) Shut down firefox.
3) Start Firefox again

Result: Firefox is positioned on the very left side of the screen.
Expected result: Firefox should be started in the position I left it.

Below is a diff that shows what changes are done by Firefox to my localstore.rdf file between step 2 and 3:

--- localstore.rdf_correct 2008-03-21 03:45:28.000000000 +0100
+++ localstore.rdf_wrong 2008-03-21 03:48:25.000000000 +0100
@@ -1,21 +1,17 @@
 <?xml version="1.0"?>
 <RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#"
          xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
+ <RDF:Description RDF:about="chrome://browser/content/browser.xul">
+ <NC:persist RDF:resource="chrome://browser/content/browser.xul#main-window"/>
+ <NC:persist RDF:resource="chrome://browser/content/browser.xul#sidebar-box"/>
+ <NC:persist RDF:resource="chrome://browser/content/browser.xul#sidebar-title"/>
+ </RDF:Description>
   <RDF:Description RDF:about="chrome://browser/content/browser.xul#main-window"
                    screenY="25"
                    sizemode="normal"
                    width="1093"
                    height="1122"
- screenX="499" />
+ screenX="0" />
   <RDF:Description RDF:about="chrome://browser/content/browser.xul#sidebar-title"
                    value="" />
- <RDF:Description RDF:about="chrome://browser/content/browser.xul#sidebar-box"
- sidebarcommand=""
- width=""
- src="" />
- <RDF:Description RDF:about="chrome://browser/content/browser.xul">
- <NC:persist RDF:resource="chrome://browser/content/browser.xul#main-window"/>
- <NC:persist RDF:resource="chrome://browser/content/browser.xul#sidebar-box"/>
- <NC:persist RDF:resource="chrome://browser/content/browser.xul#sidebar-title"/>
- </RDF:Description>
 </RDF:RDF>

This problem has been observed in all Ubuntu releases that I can remember. Info about my Ubuntu installation and Firefox installation:

Description: Ubuntu hardy (development branch)
Release: 8.04

firefox:
  Installed: 3.0~b4+nobinonly-0ubuntu1
  Candidate: 3.0~b4+nobinonly-0ubuntu1
  Version table:
 *** 3.0~b4+nobinonly-0ubuntu1 0
        500 http://se.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
Architecture: i386
Date: Fri Mar 21 03:46:38 2008
DistroRelease: Ubuntu 8.04
Package: firefox 3.0~b4+nobinonly-0ubuntu1
PackageArchitecture: all
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-12-generic i686

Created attachment 279473
394768-1.diff

Created attachment 279476
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.

Created attachment 279577
394768-3.diff

Comment on attachment 279577
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?

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.

*** Bug 421686 has been marked as a duplicate of this bug. ***

Binary package hint: firefox-3.0

Firefox forgets the location of the main window each time I close it down and start it back up. I have investigated this, and it turns out that Firefox rewrites parts of the localstore.rdf file in my profile, and thus changes the screenX="499" setting to screenX="0" as can be seen in the below diff.

Steps to reproduct:
1) Start firefox and move the main window until it touches the right edge of the screen.
2) Shut down firefox.
3) Start Firefox again

Result: Firefox is positioned on the very left side of the screen.
Expected result: Firefox should be started in the position I left it.

Below is a diff that shows what changes are done by Firefox to my localstore.def file between step 2 and 3:

--- localstore.rdf_correct 2008-03-21 03:45:28.000000000 +0100
+++ localstore.rdf_wrong 2008-03-21 03:48:25.000000000 +0100
@@ -1,21 +1,17 @@
 <?xml version="1.0"?>
 <RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#"
          xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
+ <RDF:Description RDF:about="chrome://browser/content/browser.xul">
+ <NC:persist RDF:resource="chrome://browser/content/browser.xul#main-window"/>
+ <NC:persist RDF:resource="chrome://browser/content/browser.xul#sidebar-box"/>
+ <NC:persist RDF:resource="chrome://browser/content/browser.xul#sidebar-title"/>
+ </RDF:Description>
   <RDF:Description RDF:about="chrome://browser/content/browser.xul#main-window"
                    screenY="25"
                    sizemode="normal"
                    width="1093"
                    height="1122"
- screenX="499" />
+ screenX="0" />
   <RDF:Description RDF:about="chrome://browser/content/browser.xul#sidebar-title"
                    value="" />
- <RDF:Description RDF:about="chrome://browser/content/browser.xul#sidebar-box"
- sidebarcommand=""
- width=""
- src="" />
- <RDF:Description RDF:about="chrome://browser/content/browser.xul">
- <NC:persist RDF:resource="chrome://browser/content/browser.xul#main-window"/>
- <NC:persist RDF:resource="chrome://browser/content/browser.xul#sidebar-box"/>
- <NC:persist RDF:resource="chrome://browser/content/browser.xul#sidebar-title"/>
- </RDF:Description>
 </RDF:RDF>

This problem has been observed in all Ubuntu releases that I can remember. Info about my Ubuntu installation and Firefox installation:

Description: Ubuntu hardy (development branch)
Release: 8.04

firefox:
  Installed: 3.0~b4+nobinonly-0ubuntu1
  Candidate: 3.0~b4+nobinonly-0ubuntu1
  Version table:
 *** 3.0~b4+nobinonly-0ubuntu1 0
        500 http://se.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
Architecture: i386
Date: Fri Mar 21 03:46:38 2008
DistroRelease: Ubuntu 8.04
Package: firefox 3.0~b4+nobinonly-0ubuntu1
PackageArchitecture: all
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-12-generic i686

description: updated
Saraphim (sbrofeldt) wrote :

I confirm this behaviour. It should be specified that it does not have to be moved to touch the right border - any positioning will be reset to the upper left corner.

Andres Herrera (andresh) wrote :

Confirmed, maybe you can review in Upstream and see whether or already reported, but this report is well https://wiki.ubuntu.com/Bugs/Upstream/Mozilla

Changed in firefox-3.0:
status: New → Confirmed
John Vivirito (gnomefreak) wrote :

Mozilla Team is able to reproduce this bug left confirmed and filed bug upstream since this isnt something that came from our package.
https://bugzilla.mozilla.org/show_bug.cgi?id=431921

Changed in firefox:
status: Unknown → New
John Vivirito (gnomefreak) wrote :

Andres i spent an hour looking for bug upstream and i do this all the time while you were typing that. Finally someone that thinks like me ;)

*** Bug 431921 has been marked as a duplicate of this bug. ***

Changed in firefox:
status: New → Invalid
John Vivirito (gnomefreak) wrote :

updated upstream bug URL

Changed in firefox:
status: Unknown → In Progress
teseglet (mobil1guru) wrote :

Same problem here with Hardy and Firefox 3 and window placement on "centered"...only Firefox window goes to upper left...randomly...sometimes. None of my other applications have this problem. I have the same problem with Firefox when using 'Fixed Window Placement". Sometimes it goes where I have placed it, sometimes it opens in the upper left. Very strange.

Tom (thomasbuhmann) wrote :

Same problem with Hardy and Firefox 3.0.4

Tom (tom6) wrote :

errr, uh oh. It seems i have the same user-name as someone else. I'm new

Tom (tom6) wrote :

Tom is such an excellent name tho, i dont understand why everyone doesn't want to use it

Tom (tom6) wrote :

i found it interesting about the localstore.rdf file. Something that annoys me in Windows is that it tries to line up all my useful desktop icons neatly on the left and then splats any and every window over the top of them quite rudely unless i have carefully opened that particular window up before and carefully placed it somewhere reasonable

Alexander Sack (asac) on 2008-12-27
Changed in firefox-3.0:
status: Confirmed → Triaged
Kevin Herrera (kherge) wrote :

I'm currently experiencing window position remember issues as well.

Ubuntu 8.10
GNOME 2.24.1

Changed in firefox:
importance: Unknown → Medium

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.

Thomas Hotz (thotz) on 2012-10-18
affects: firefox-3.0 (Ubuntu) → firefox (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.