35569 - transient popup windows position in the wrong place (at +0+0)

Status: NEW

(Core :: XUL, defect, P3)

Description

[Chris Siebenmann]

Build ID: 2000041109

 Transient windows (dialog windows, popup windows, modal dialogs) always
seem to pop up at the top left corner of the screen (+0+0 in X parlance).
This behavior seems to be for all transient windows, whether particularly
related to the current window they're spawned from or not: eg both the
Preferences dialog window and the Find In Page dialog do it.

 This is new since M14, which had transient windows appearing in the
right place.

 Reproduction: start Mozilla. Position the window at the lower right
corner of the screen. Alt+F a Find dialog; observe that it appears
nowhere near the window.

 Environment: Redhat 6.1 GNOME or fvwm2 2.2.2 as the window manager
environment. No special window manager settings.

 I suspect that this may be an all-platform bug: bug #29371 and
bug #33321 cover similar things on Mac and Windows.

Comment 1

[Peter Trudelle]

reassigning to danm for triage.  how is placement of these windows being handled
now?

Comment 2

[Peter Trudelle]

mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-

Comment 3

[Dan M]

  It'd be nice if transient windows were initially placed relative to their 
parent, barring placement from persisted position attributes, anyway. The two 
windows mentioned (preferences, find in page) initially show up in the upper left 
on Windows builds, but then when repositioned, closed and reopened, reappear at 
their persisted, repositioned place.
  Are we still disallowing window placement on unices, deferring instead to the 
Window Manager? Reassigning to the Holder of Unix Window Placement Religion for 
further consideration.

Comment 4

[Stuart Parmenter]

if the window manager was positioning the transient windows, they would be
coming up in the "right place."  I suspect we are moving them to 0x0 since we
don't have a persistant state for them....  ugh.  I hate persistant window
location.

Comment 5

[Stuart Parmenter]

not sure what to do with this, moving to M25.. my "uhh... what do i do with
this" milestone

Comment 6

[Peter Trudelle]

this doesn't seem to be happening anymore, was it fixed by a related bugfix,
wfm, or what?  In the meantime, ->future.

Comment 7

[janne hayrynen]

linux build 2001031408

at the moment, it seems like mozilla is not giving out window manager hints at all.

with enlightenment, the default behaviour is to economically place windows and
find least occupied part of screen for them, and this is what i see with all
mozilla windows and dialogs. enlightenment has an option "place dialogs together
with their owner" but at least with my e-0.16.4 this makes no difference with
mozilla at all, dialogs still appear all over the desktop where there is space.

netscape4.7x places all dialog windows correctly together with their owner, so
it obviously uses the window manager hints.

i just submitted a bug about mozilla navigator windows not using wm hints on X
(bug 72330), and i think that all mozilla windows, be they
navigator/dialogs/pref/mail etc should be able to use windowmanager hints for
correct placement, cascading and so on.

if this is not what user wants, then it would be nice to have a preference to
completely disable window manager hints so pavlov doesn't have to go berserk
over this.

Comment 8

[Kathleen :Brade]

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

Comment 9

[Mike Shaver (:shaver emeritus)]

This really is quite obnoxious.  Pav?  Bliz?  Any hope?

Comment 10

[Christopher Blizzard (:blizzard)]

I haven't seen this in a very, very long time.  I fixed a bug in the last couple
of months that was related to tooltips but I haven't seen anything like this in
a long long time.

Comment 11

[Chris Siebenmann]

 Opening a Search | Find In This Page window, either from the menu or from
the shortcut key, reliably opens it at +0+0 for me with a current build from
CVS.

 This is under fvwm2 (as with my original report).

Comment 12

[Christopher Blizzard (:blizzard)]

How strange.  With sawfish it comes up in the middle of the screen.  I wonder if
there's something about how we move the window to it's location.  Do we use a
hint?  I can't remember.

Comment 13

[Chris Siebenmann]

 After spelunking fvwm2 code, I believe that what is happening is that the
transients are specified as being transients but have no position specified.
In this case fvwm2 (and presumably other window managers) defaults to placing
the window in the top-left.

 I suspect that the best solution is to explicitly work out and set a location
relative to the parent window.

Comment 14

[Mark Purtill]

This happens for me running KDE 2.1; it's especially annoying as I have the
toolbars at the top, and some of the transients (e.g., Find in this Page) appear
under the toolbar.

Comment 15

[ow]

Similar (the same) issue with Mozilla 1.2.1 on Windows XP.
Also, there's a way to make IE remember a popup window's size and position. In
other words, when a new window opens, it opens in a certain place with a certan
size. Would be nice to have the same in Mozilla.

Comment 16

[Frank J. R. Hanstick]

The top of the popup window always tries to align itself with the top of the main window no matter where it is placed.  Periodically, the top of the popup window goes above the top of the main window even when the main window abuts against the menu which puts the top of the popup window under the menu bar where it can no longer be moved or closed.  The Firefox version is 2.0.0.4 and the MacOS 10.4.10.  The system is a dual 800MHz PowerPC G4 Quicksilver upgraded to a dual 1.73 GHz PowerPC G4 7448.  The problem appeared under earlier versions of the MacOS 10.4 series and before the CPU upgrade.