browser window position always (0,0) ? [gtk2]

RESOLVED FIXED in Firefox0.9



15 years ago
9 years ago


(Reporter: Danny Milosavljevic, Assigned: blizzard)


({fixed-aviary1.0, fixed1.7.5})

fixed-aviary1.0, fixed1.7.5
Dependency tree / graph
Bug Flags:
blocking-aviary1.0PR +

Firefox Tracking Flags

(Not tracked)



(1 attachment, 2 obsolete attachments)



15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030611 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030611 Mozilla Firebird/0.6

I'm using mozilla-firebird 0.6... it works great...

There is only one weirdness:

A new browser window (also the default window when starting MozillaFirebird)
will always open at (0,0) at the top left corner of the screen here...

I don't know why, even the localstore.rdf *has* stored the last used position
into screenX, screenY for chrome://browser/content/browser.xul#main-window,
which I assume means that window?

Also, parameter "-geometry" doesn't work/exist... is there a X resource to set
the position ?

What I'm getting at, the way it is now, the Mozilla Firebird browser window is
partially beneath my (system) panel which is a lil weird... so I want to set it
to (0,50)... how ?

Other than that its nice :)

Reproducible: Always

Steps to Reproduce:
1. Start "MozillaFirebird" (of firebird 0.6)

Actual Results:  
window opens and get placed (by firebird itself, it seems) at the top left
corner, at (0,0)

Expected Results:  
- window opens and gets placed by the windowmanager like every other window 
- window opens and gets placed (by firebird) where I left it the last time

Comment 1

15 years ago
Well, at least for the -geometry stuff there already exists a bug #20573
David, does this happen for you?

Comment 3

15 years ago
I never noticed this as I always maximize the browser window, but yes, it is
occurring. It will remember size but not position. Thunderbird also does the
exact same thing, so the bug may lie in somewhere in toolkit/?. Mozilla doesn't
even remember size. By contrast, all KDE apps open in the same position and size
that you closed them in, which ought to be what we do.

--> Confirming
Ever confirmed: true

Comment 4

15 years ago
I can confirm the bug too, but I only have the problem with builds in which GTK2
and XFt are enabled. This means: the official nightlies with the package name
"MozillaFirebird-i686-pc-linux-gnu.tar.gz" remember their position (but the
fonts look horrible on my system), official nightlies with the package name
"MozillaFirebird-i686-linux-gtk2+xft.tar.gz" don't remember their position


15 years ago
QA Contact: asa

Comment 5

15 years ago
I just build FB0.7 with Xft and GTK2. Contrary to
MozillaFirebird-0.7-i686-pc-linux-gnu-deDE.tar.gz my result cannot remember its
desktop position which it had before closing the application. It always opens at
the upper left corner (Pos. 0,0). I used similar compile options for
Mozilla1.5rc2. That one works fine in these premises.
All new gtk2 firebird and thunderbird windows open at top left corner (they
avoid panels ok though), using metacity 2.6.[23], with gconf key
/apps/metacity/general/disable_workarounds unset. If that gconf key is set,
placement seems to work fine.

With disable_workarounds=false, comparing Metacity verbose logs on opening a
firebird-gtk2 window against opening a gedit window (which gets placed
properly), the relevant difference seems to be:

     PLACEMENT: Not placing window with PPosition or USPosition set

Are gtk2 mozilla apps setting some bogus hints?

Comment 7

15 years ago
I experience the same thing in Fedora Core 1 (Mozilla 1.4.1 and updating to 1.5
didn't solve the problem) and setting /apps/metacity/general/disable_workarounds
only seems to center the window, not restoring the actual X and Y starting pos.

Comment 8

14 years ago
->ben for 0.9 evaluation.
Assignee: firefox → bugs
Target Milestone: --- → Firefox0.9

Comment 9

14 years ago
*** Bug 233449 has been marked as a duplicate of this bug. ***

Comment 10

14 years ago
*** Bug 236524 has been marked as a duplicate of this bug. ***

Comment 11

14 years ago
Zinf, which also recently switched to GTK+ 2.0, also stopped remembering where
to place itself recently. Is it possible that the toolkit is responsible?


Comment 12

14 years ago
according to 'xprop', firefox and thunderbird windows (and i assume mozilla as
well) are forcing their own position:

                program specified location: 0, 0
                program specified minimum size: 0 by 0
                window gravity: NorthWest

this is from firefox 0.8, gtk2+xft.  all new windows are placed in the top-left
corner of the screen.

to compare, i grabbed a copy of firefox 0.8, gtk1.2 build:

                program specified size: 200 by 200

that and subsequent new windows are placed by the window manager at various
places on the screen (IMHO the correct behavior).

while i wouldn't consider this a "critical bug" by far, it's easily in my top 5
list of major annoyances out of all the apps i run.

since this appears on the surface to be a gtk2 issue, perhaps blizzard might
have some input as to what's going on?  (i'd cc: him myself, but i'm not sure of
the etiquette of such a thing.)


14 years ago
Summary: browser window position always (0,0) ? → browser window position always (0,0) ? [gtk2]

Comment 13

14 years ago
I found bug 217639, which this bug duplicates, I think.

Comment 14

14 years ago
Asa said he thought bug 217639 would not be a dupe due to possible different
fixes, but I'm guessing this probably will depend on whatever fix goes in there.
Created attachment 145507 [details] [diff] [review]
trial patch

This patch seems to work for me.
When initially creating the window, we do want to set the size, but not the
But i don't really know gtk2 widget code, so i hope this is the right thing to
do. So far, I couldn't find any weirdness.
Attachment #145507 - Flags: review?(blizzard)

Comment 16

14 years ago
Comment on attachment 145507 [details] [diff] [review]
trial patch

I'm pretty sure this will cause occasional problems with menus and other
widgets that do actually have to set their location on the window.  Even so,
this is certainly the wrong way to fix this problem.
Attachment #145507 - Flags: review?(blizzard) → review-

Comment 17

14 years ago
I'm wondering if we're passing the location down incorrectly, or not at all? 
The 0,0 position makes me think we're mis-parsing the location of the window. 
I've also never seen this bug personally.  My windows tend to start up the last
place that I left them.
afaik, top level windows shouldn't have a position. It's the window managers job
to place them. Other apps open in either a free space on the desktop, or stacked
to the top left. (next window has some more offset) mozilla windows all open at
absolute top left, even on empty screens. They should open at about 100,100 instead.
From what i have seen, mozilla moves the window to 0,0 when resizing the window
to the right size.
And i haven't seen any problems so far. Not that that mean it definitly works...
(In reply to comment #16)
> I'm pretty sure this will cause occasional problems with menus and other
> widgets that do actually have to set their location on the window.  Even so,

No problems so far, all windows, dialogs and menus appear are where I expect
them to appear with the patch (firefox & thunderbird).

(In reply to comment #17)
> I've also never seen this bug personally.  My windows tend to start up the last
> place that I left them.

I can't reproduce that behaviour with sawfish 1.3 (with any placement scheme) or
metacity 2.6.5 with or without the above patch.

(In reply to comment #18)
> From what i have seen, mozilla moves the window to 0,0 when resizing the window
> to the right size.

On a related note, javascript:window.resizeTo(x,y); will still move a window to
top left even with this patch. Similarly knifing the 3-parameter version of
nsCommonWidget::Resize to always use the 3-parameter version of NativeResize
"fixes" that problem, for lack of better wording.

Comment 20

14 years ago
Just wanted to point out that with a dual screen setup this is one of the most
important bugs for mozilla right now. Having a second screen to the left makes
all mozilla windows pop up completely wrong (left screen instead of right).
Having to drag each new window over to the preferred screen is major pain in the

My point with this is that although this bug might seem minor to many, it
quickly grows to something that makes people seriously consider throwing out
mozilla once you have a dual screen setup.

I'm currently running metacity 2.6.2 and is available for any kind of patch
testing since I *really* want to see this bug fixed.

Comment 21

14 years ago
My point was that the patch as it exists only happens to work because it removes
the window move before a ::Show call.  This is "fixing" the problem as a side
effect of what is essentially introducing a bug into the widget code.

There's a deeper bug here somewhere in that the placement hint is set at 0,0
instead of at the correct location.  Since I can't reproduce, you guys need to
find out where that is happening.  comment 6 seems to have a good clue.
From what is getof the code, for a new window we only resize it to the size we
want. It is never moved. But it has x,y coordinates internally, and those
default to 0,0.
When showing the window it is resized and moved. But the x,y coordinates where
never filled in, so are still 0,0.
My patch removes the moving when showing the window, so the windowmanager takes
the task of finding a suitable spot for placing.
The question is: Should mozilla move the window to a sane location, or should it
not move it at all? If the former, how does is know that position?

Comment 23

14 years ago
personally, i'm in favor of removing any position-setting code whatsoever for
new toplevel windows.  i trust my window manager to pick a good spot.  if moz
saves the window position on close (tangent: if you have multiple windows open,
which does it save, and why?), and then i restart, it will put all new windows
in the same location.  that seems rather counterproductive, as i'm guaranteed to
have to move the windows around so they aren't overlapping.  i really can't
think of a good use case where you'd _want_ successive windows to all be in the
same place, 100% obscuring already-present windows.

Comment 24

14 years ago
I don't mind making sure that the position is unset as well, but the current
patch is not the way to do it.  Need to have an "this is unset" flag or something.

Comment 25

14 years ago
Created attachment 145703 [details] [diff] [review]
patch that only places the window if someone has set an explicit position

How about this patch?  This will only set the toplevel window position if
someone has called Move() or Resize(x,y,...) on the window.  I can't test it
since I can't reproduce the problem here.
Attachment #145507 - Attachment is obsolete: true


14 years ago
Attachment #145703 - Flags: superreview?(bryner)
Attachment #145703 - Flags: review?(bryner)
Yes, attachment 145703 [details] [diff] [review] appears to work ok: windows, dialogs and menus appear
where they should; javascript:window.resizeTo(x,y) no longer causes windows to
move, except in one remaining scenario that I know of:
 1. Move a window using javascript:window.moveTo(600,400);
 2. Drag the window elsewhere
 3. Resize the window using javascript:window.resizeTo(600,400);
Expected: stay put at position given at step 2
Actual: moves to position given at step 1

Since that is a rather uncommon scenario, would you prefer a new bug for that?
The hack-around in comment 19 works for the remaining issue in comment 26. The
use of 5-parameter NativeResize in the 3-parameter Resize was added in bug
173640, so removing it could regress at least that. I don't have a seamonkey
gtk2 build set up to verify that it does, though.

Comment 28

14 years ago
I confirm that the patch works fine :)



Comment 29

14 years ago
bug #228590 maybe is also gtk2 related ? 

Doesn't seem anyone else hit bug #228590 except me...
Whereas I have it with every firefox version (0.6, 0.7, 0.8), and every gtk+ 
version (2.2.x, 2.4.0) I tried, always ;)
Attachment #145703 - Flags: superreview?(bryner)
Attachment #145703 - Flags: superreview+
Attachment #145703 - Flags: review?(bryner)
Attachment #145703 - Flags: review+

Comment 30

14 years ago
The moveTo and resizeTo problems happen whether or not this patch is applied. 
That is a seperate bug, something I'll file.


14 years ago
Assignee: bugs → blizzard

Comment 31

14 years ago
The resizeTo problem is in bug #240327.  However, I suspect that these two
problems are closely related.  I suspect I should set mPlaced when we get a
configure event since ::MoveTo is never called on the toplevel window.

Comment 32

14 years ago
Also, why aren't we tracking mBounds.x and mBounds.y for toplevels for configure
events?  I think we're supposed to be, but I can't remember why we aren't.  
Seems like a serious oversight.

Comment 33

14 years ago
Created attachment 146029 [details] [diff] [review]
new patch that fixes moveTo and resizeTo problems

New patch that fixes the resizeTo and moveTo problems.	This keeps track of x/y
coordinates as well as keeping the coordinates in the right coordinate system.
Attachment #145703 - Attachment is obsolete: true


14 years ago
Blocks: 92033
Bonus points for using PRPackedBool for the new member (and the two above it?).

Comment 35

14 years ago
I seem to remember someone telling me that any advantage from PRPackedBool is a
myth.  That is, it's aligned, but actually requires more space because accessing
the variable requires more code generated from the compiler, as well as being


14 years ago
Blocks: 240327

Comment 36

14 years ago
*** Bug 241275 has been marked as a duplicate of this bug. ***


14 years ago
Attachment #146029 - Flags: superreview?(bryner)
Attachment #146029 - Flags: review?(bryner)

Comment 37

14 years ago
I've been using this patch in my daily tree for quite some time now with no ill
effects that I can see.
Attachment #146029 - Flags: superreview?(bryner)
Attachment #146029 - Flags: superreview+
Attachment #146029 - Flags: review?(bryner)
Attachment #146029 - Flags: review+
Flags: blocking0.9+
blizzard, if you haven't seen anything in the way of negative impact yet, can we
get this in, at least on the aviary branch, so we can get some testing on the
pre-0.9 branch builds?
I checked this in on the aviary 1.0 branch. 
Whiteboard: fixed-aviary1.0

Comment 40

14 years ago
Checked in.
Last Resolved: 14 years ago
Resolution: --- → FIXED
*** Bug 217639 has been marked as a duplicate of this bug. ***

Comment 42

14 years ago
Reopening : bug is still there with firefox nightly build (20040803) and when
applying chris patch on 1.7 tree.

Size is ok but positioning is still 0x0
Resolution: FIXED → ---

Comment 43

14 years ago
Blizzard, Ben, can you guys take a look at this. I just tested today's branch
gtk2 installer build and the app refuses to remember it's window position,
starting each time at 0,0.
The part I gather was fixed here, i.e. all windows always opening at top left
instead of expected placement by wm (metacity 2.8.1), worksforme on linux
firefox aviary gtk2 cvs 2004-08-04-10Z and nightly 2004-08-03-08-0.9, gtk2
nightly 2004-08-03-14-trunk.

I wonder if it might be clearer to split off the lack of window position
persistence across sessions, since the expected results in comment 0
(positioning by wm option) wfm

Comment 45

14 years ago
Maybe someone is actually setting the position to 0,0?  The code that I checked
in, and I think is on the aviary branch, doesn't set the position at all if no
one has set it.

Comment 46

14 years ago
This makes Firefox on Linux pretty horrible to use. Setting blocking flag.
Flags: blocking-aviary1.0PR+

Comment 48

14 years ago
moving fixed-aviary1.0 from whiteboard to keyword
Keywords: fixed-aviary1.0
Whiteboard: fixed-aviary1.0
Flags: blocking0.9+

Comment 49

14 years ago
Is this patch needed for 1.7?

Comment 51

14 years ago
Patch checked into 1.7.
Keywords: fixed1.7.5

Comment 52

13 years ago
Is there any more work to be done on this bug?
If it hasn't even gotten comments about things which are not actually it for 2.5 years, its work is done.
Last Resolved: 14 years ago11 years ago
QA Contact: general
Resolution: --- → FIXED

Comment 54

9 years ago
On ubuntu 8.04, with IceWM, firefox reposition itself at (0,0)
but mantain the window size.

On ubuntu 8.04, with gnome, it works correctly.

FF version: 3.0.11

Comment 55

9 years ago
Update 4 error: ALSO with gnome FF repositions itself at (0,0)
You need to log in before you can comment on or make changes to this bug.