217639 - [gtk2] The browser will always start up at pixel 0x0 if built with GTK+2

Status: RESOLVED DUPLICATE of bug 209342

(Core Graveyard :: GFX: Gtk, defect)

Description

[Colin Ligertwood]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030812
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030812

below is my build config. ive confirmed this with a friend who also built his
own lizard against gtk+2. its really quite simple. the browser isnt saving any
kind of session data. everytime i start it up it starts a browser at the top
left of the screen of default size.  if i build against gtk1, it remembers its
last position and size.


ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize
ac_add_options --without-system-nspr
ac_add_options --without-system-zlib
ac_add_options --without-system-jpeg
ac_add_options --without-system-png
ac_add_options --without-system-mng
ac_add_options --enable-crypto
ac_add_options --enable-strip
ac_add_options --enable-strip-libs
ac_add_options --enable-xft
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --disable-toolkit-gtk
ac_add_options --enable-toolkit=gtk2
ac_add_options --enable-extensions=default,-inspector,-help,-irc,-venkman
ac_add_options --disable-installer
ac_add_options --disable-dtd-debug
ac_add_options --disable-logging
ac_add_options --enable-strip


Reproducible: Always

Steps to Reproduce:
1. build mozilla w/ gtk2
2. start mozilla and move the window and resize the window and quit
3. start mozilla


Actual Results:  
the mozilla browser window reapeared with the top left corner at 0x0

Expected Results:  
mozilla should have restarted in the place and size it was when i last quit

Comment 1

[Daniel Ceregatti]

Ditto.

Comment 2

[Boris Zbarsky [:bzbarsky]]

.

Comment 3

[Christopher Blizzard (:blizzard)]

Works here.  What window manager, just out of curiousity?

Comment 4

[Colin Ligertwood]

im using XFCE. the latest version.  ive also experienced it with e.

Comment 5

[Daniel Ceregatti]

I use Enlightenment with its "best fit" window placement algorithm by default.
It'll place windows which don't explicitly set their own geometry. This tells me
that gtk2 is forcing the geometry. Or perhaps mozilla itself somehow is setting it?

This happens to EVERY window mozilla spawns, without exceptions.

I've checked Enlightenment's "Remember" settings and it's not set to remember
mozilla or anything related to gtk.

Other gtk2 apps don't have this issue.

I've tried mozilla 1.3 and 1.4 with gtk2. Both are affected.

Also, note that the bug is that the windows open at +0+0 geometry, not 0x0,
which implies a window with no size. The size for me is remembered properly by
mozilla, but the position is always +0+0. Bad Colin!

Comment 6

[Pierre Ossman]

Same problem here. Size is remembered, position is always +0+0.

I'm using metacity wm.

I also have a dual-head setup which makes this extra annoying since the
mozilla/firebird windows will pop up on the left screen instead of the right
(where everything else gets placed by the wm).

I've tried changing the build settings but the only one that affects this
behaviour is switching to and from gtk2.

Comment 7

[Tuukka Tolvanen (sp3000)]

Doh! _Now_ I find this bug. See bug 209342 comment 6.

confirmed with thunderbird 0.3, firebird 20031119, seamonkey trunk 20031119.
All windows of gtk2 builds always open at top left using metacity 2.6.[23] with
gconf /apps/metacity/general/disable_workarounds=false; a perhaps relevant bit
in metacity verbose log looks like
    PLACEMENT: Not placing window with PPosition or USPosition set

Comment 8

[Daniel Ceregatti]

Still here in 1.6.

Comment 9

[Wolfgang Rosenauer [:wolfiR]]

all GTK2 builds show this behaviour for me using WindowMaker. It seems Mozilla
sets the PPosition hint for windowmanagers.

Comment 10

[Felix Miata]

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

Comment 11

[Felix Miata]

The xft/gtk2 1.6 shipping in Mandrake 10 Community does this.

Shouldn't bug 209342 depend on this?

Comment 12

[Wolfgang Rosenauer [:wolfiR]]

hmm, I don't know what happened but for it does work now with 1.8a2 built from
yesterdays trunk.

Comment 13

[Tuukka Tolvanen (sp3000)]

fixed on trunk in bug 209342 afaict.

*** This bug has been marked as a duplicate of 209342 ***