100339 - with xinerama support, the 'Sending Message - ' dialog is placed wrong

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[Chris P. Ross]

This is only evident with --enable-xinerama turned on, so it's going to
be a bit tricky to replicate and debug.  Sorry about that.

After applying the patch noted in bug #74870, so that most mozilla dialogs
appear properly on my second screen; the "Sending" progress dialog for
sending messages appear on my first screen.  Where there are no other
mozilla windows.

I did a bunch of testing, and have found that that "sending" dialog seems
to always appear on the screen with a 0,0 origin.  Whether that be screen
0, or 1; and whether mozilla is on that screen, or the other.  When mozilla
is on that screen, that dialog appears near the top of, effectively inside,
the composition window.

I presume that the issue here may not actually be a mail/news problem,
but a more generic dialog problem.  But, as all other dialogs I typically
see (unsecure submission warning; mail password; and cookie verification) all
now appear correctly in the middle of the screen mozilla is running on,
I have attributed this to mail/news.  I suspect it might actually just
be an issue of what the dialog is parented to.  I'm not familiar enough
with the code to test that theory, but I'd be happy to hear thoughts
from anyone more familiar with the dialog code in mozilla.  Is that dialog
parented differently than the other dialogs I mention above that are working
properly for me?

I'll be happy to test any suggestions you may have, as I have a Xinerama
workstation here.  :-)  For the moment, at least.

Comment 1

[Jeffrey Baker]

Here's my question.  Why is Mozilla placing windows?  That is what my window
manager is for.  It knows how to place a dialog box in the center of a screen. 
Mozilla does not.  We have an existing mechanism for this, and Mozilla doesn't
need to reinvented it poorly.

Comment 2

[Chris P. Ross]

Perhaps my complaint is misplaced.  I'm not 100% certainly that mozilla is
placing the dialogs.  But, whatever mozilla is doing is different in the
case that Xinerama support is enabled, and gets these wrong.

The second piece of info is that the "What do you want me to do with
MIME type 'X' file you've just asked for?" dialog is also wrong.  Strangely,
it seems to be in the middle of the two screens on my xinerama setup.
This dialog also worked just fine without xinerama support, displaying only
on the correct screen.  I have no idea why it's gotten *worse* by adding
the xinerama support.

Would this lend creedance to the idea that it's an issue of who
the dialog's parent is?

Comment 3

[Chris P. Ross]

Looking at the comments in bug#32612, I think this is a "known deficiency"
of blizzard's implementation.  I presume it's based on the GetPrimaryScreen
function always returning screen 0.

Perhaps now would be a good time to look into how to more intelligently choose a
primary screen?  Any thoughts on this, Chris [Blizzard]?

Comment 4

[Christopher Blizzard (:blizzard)]

With Xinerama the 0 screen is almost always the primary screen.  I mean,
Xinerama isn't as cool as the mac and doesn't have the toolbar on one screen and
not on another.  It makes it all guess work.

Comment 5

[Chris P. Ross]

True enough, but can't you use the getrect stuff, and determine which of the
xinerama screens has the majority of the parent mozilla window on it?  That
should be the "right" screen...

Comment 6

[Jeffrey Baker]

I still object to dicking around with window placement like that.  My window
manager works perfectly well, and only Mozilla manages to place dialogs half on
one screen and half on the other.

Comment 7

[Chris P. Ross]

But there's a difference between a window, and a dialog.  Mozilla doesn't
place windows.  It places dialogs.  While they are technically windows,
from a U/I point of view, they're a totally different animal.

Do you have other applications that bring up dialogs that your window
manager is asked to place?

Comment 8

[Jeffrey Baker]

Yes of course.  The window manager is perfectly capable of placing dialogs!  In
fact, the only way I get reasonable placement of Mozilla's dialogs is if I tell
the window manager to ignore program-specified dialog positions and just
position all dialogs under the pointer but not spanning screens (which is where
they belong, IMHO).

If I let Mozilla position the window it puts it squarely in the center of the
display, which is just horrible.

Comment 9

[Chris P. Ross]

You are very much entitled to your own opinion, and if that's where you'd
prefer dialogs, I'm happy you have found a way to get it to happen.

But, myself, I would much prefer my dialogs appear in a consistant location.
Having it appear under the cursor, wherever the cursor happens to be, would
drive me nuts in a very short period of time.  Now, without the xinerama
support, they were appearing between the two physical screens, and I admit
that *that* is worse.  But, when I'm moving my cursor around the screen, 
I don't generally have a conscious notion of where it is, I just know where
I'm going.  And if I have to stop and consiously realize that a widget has
appeared, then realize where my cursor is, and move it that way; that's 
*way* against what I like to have happen, personally.  I'd much rather
know that dialog's appear in place X.

Maybe it's cause I'm a mac user, and I've been living with the Apple
HIG for so many years.  Not that I've ever had a mac with more than
one screen for more than a few test operations, but...  I'm pretty sure
all of those dialogs appear in the center of the screen.  Maybe even
the center of the "base" screen (the one with the menubar), but maybe
not.  In either case, the normal scenario has them appear somewhere
predictable, so that's what I'm used to...

Hmm.  Sorry to rant...

Comment 10

[Christopher Blizzard (:blizzard)]

There's already a call to get the window that contains a passed in rect.  You
should be able to use the rect of the window and get the screen that contains
most of that window.  There are parts of moz ( like the menu popup code ) that
use this call.  The dialogs just have to be fixed to use it and pop up over the
parent.

Comment 11

[Jeffrey Baker]

Are we just talking past each other here or what?  I don't really care where you
want your dialogs, and neither should Mozilla.  It is the job of your *window
manager* to put the dialogs where *you* want them.  For example, my window
manager is able to place dialogs in the following locations:

Centered on a screen
Centered on their parent window
Top left corner of a screenUnder the pointer
InteractivelyRandomly (!)

Hear me now or hear me later: Mozilla shouldn't try to place dialogs because
that isn't its job.  We've already seen how perplexing it can be when Mozilla
does the wrong thing with the window (swapping x/y offsets to place dialog well
off the screen).

Comment 12

[Jean-Francois Ducarroz]

reassign to correct component...

Comment 13

[Asa Dotzler [:asa]]

-> default assignee

Comment 14

[Peter Trudelle]

->xpt widgets

Comment 15

[jag (Peter Annema)]

-> future

Comment 16

[Frank Cusack]

Hear Hear.  Mozilla should definitely not be in the window placement business.

I'm running 1.0 w/ xinerama and if I try to download a file, the
"what do you want to do with this file" dialog appears on the
screen whose origin is (0,0), which in my case is NOT screen 0.
I guess that's not new information.

But then the file chooser and download status dialogs comes up
on top of the parent.  Very annoying.

Comment 17

[Sylvestre Ledru [:Sylvestre]]

BSDI isn't maintained anymore, closing.