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
Well, at least for the -geometry stuff there already exists a bug #20573
David, does this happen for you?
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
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., 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?
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.
->ben for 0.9 evaluation.
Assignee: firefox → bugs
Target Milestone: --- → Firefox0.9
*** Bug 233449 has been marked as a duplicate of this bug. ***
*** Bug 236524 has been marked as a duplicate of this bug. ***
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
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.)
Summary: browser window position always (0,0) ? → browser window position always (0,0) ? [gtk2]
I found bug 217639, which this bug duplicates, I think.
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 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.
Attachment #145507 - Flags: review?(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.
Attachment #145507 - Flags: review?(blizzard) → review-
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...
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.
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?
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.
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.
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
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.
I confirm that the patch works fine :) Thanks...
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 ;)
The moveTo and resizeTo problems happen whether or not this patch is applied. That is a seperate bug, something I'll file.
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.
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.
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
Bonus points for using PRPackedBool for the new member (and the two above it?).
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.
*** Bug 241275 has been marked as a duplicate of this bug. ***
I've been using this patch in my daily tree for quite some time now with no ill effects that I can see.
14 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
*** Bug 217639 has been marked as a duplicate of this bug. ***
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → NEW
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
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.
This makes Firefox on Linux pretty horrible to use. Setting blocking flag.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241519 The patch works fine in Debian.
moving fixed-aviary1.0 from whiteboard to keyword
Is this patch needed for 1.7?
Mandrake bug http://qa.mandrakesoft.com/show_bug.cgi?id=10308
Patch checked into 1.7.
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.
Status: NEW → RESOLVED
Last Resolved: 14 years ago → 11 years ago
QA Contact: general
Resolution: --- → FIXED
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
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.