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

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Danny Milosavljevic]

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)
2.
3.

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 
or
- window opens and gets placed (by firebird) where I left it the last time

Comment 1

[Erik]

Well, at least for the -geometry stuff there already exists a bug #20573

Comment 2

[Mike Connor [:mconnor]]

David, does this happen for you?

Comment 3

[David P James]

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

Comment 4

[Axel Horndasch]

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

Comment 5

[jhxxx]

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.

Comment 6

[Tuukka Tolvanen (sp3000)]

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

[Mattias Dahlberg]

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

[Asa Dotzler [:asa]]

->ben for 0.9 evaluation.

Comment 9

[Brian Tarricone]

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

Comment 10

[Ethan Glasser-Camp]

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

Comment 11

[Ethan Glasser-Camp]

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?

Ethan

Comment 12

[Brian Tarricone]

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

WM_NORMAL_HINTS(WM_SIZE_HINTS):
                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:

WM_NORMAL_HINTS(WM_SIZE_HINTS):
                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.)

Comment 13

[Ethan Glasser-Camp]

I found bug 217639, which this bug duplicates, I think.

Comment 14

[Felix Miata]

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.

Comment 15

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: trial patch

This patch seems to work for me.
When initially creating the window, we do want to set the size, but not the
position.
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.

Comment 16

[Christopher Blizzard (:blizzard)]

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.

Comment 17

[Christopher Blizzard (:blizzard)]

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.

Comment 18

[Michiel van Leeuwen (email: mvl+moz@)]

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

Comment 19

[Tuukka Tolvanen (sp3000)]

(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

[Pierre Ossman]

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

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

[Christopher Blizzard (:blizzard)]

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.

Comment 22

[Michiel van Leeuwen (email: mvl+moz@)]

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

[Brian Tarricone]

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

[Christopher Blizzard (:blizzard)]

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

[Christopher Blizzard (:blizzard)]

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

Comment 26

[Tuukka Tolvanen (sp3000)]

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?

Comment 27

[Tuukka Tolvanen (sp3000)]

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

[Danny Milosavljevic]

I confirm that the patch works fine :)

Thanks...

Comment 29

[Danny Milosavljevic]

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 ;)

Comment 30

[Christopher Blizzard (:blizzard)]

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

Comment 31

[Christopher Blizzard (:blizzard)]

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

[Christopher Blizzard (:blizzard)]

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

[Christopher Blizzard (:blizzard)]

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

Comment 34

[Christopher Aillon (sabbatical, not receiving bugmail)]

Bonus points for using PRPackedBool for the new member (and the two above it?).

Comment 35

[Christopher Blizzard (:blizzard)]

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

Comment 36

[José Jeria]

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

Comment 37

[Christopher Blizzard (:blizzard)]

I've been using this patch in my daily tree for quite some time now with no ill
effects that I can see.

Comment 38

[Mike Connor [:mconnor]]

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?

Comment 39

[Ben Goodger (use ben at mozilla dot org for email)]

I checked this in on the aviary 1.0 branch. 

Comment 40

[Christopher Blizzard (:blizzard)]

Checked in.

Comment 41

[Tuukka Tolvanen (sp3000)]

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

Comment 42

[Frederic Crozat]

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

Comment 43

[Asa Dotzler [:asa]]

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.

Comment 44

[Tuukka Tolvanen (sp3000)]

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

[Christopher Blizzard (:blizzard)]

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

[Asa Dotzler [:asa]]

This makes Firefox on Linux pretty horrible to use. Setting blocking flag.

Comment 47

[Scott Robinson]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241519

The patch works fine in Debian.

Comment 48

[chris hofmann]

moving fixed-aviary1.0 from whiteboard to keyword

Comment 49

[Mike Kaply [:mkaply]]

Is this patch needed for 1.7?

Comment 50

[Felix Miata]

Mandrake bug http://qa.mandrakesoft.com/show_bug.cgi?id=10308

Comment 51

[Mike Kaply [:mkaply]]

Patch checked into 1.7.

Comment 52

[mmc]

Is there any more work to be done on this bug?

Comment 53

[Phil Ringnalda (:philor)]

If it hasn't even gotten comments about things which are not actually it for 2.5 years, its work is done.

Comment 54

[Roberto Colmegna]

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

[Roberto Colmegna]

Update 4 error: ALSO with gnome FF repositions itself at (0,0)