9131 - Problems with positioning of find dialog

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[cpratt]

Build ID: 1999070108, 1999063009
Platform: Windows 98, Windows NT, Linux, Mac OS 8.6

To reproduce:
- Launch apprunner
- Select 'Find On this page…' from the Search menu

Result:
- Invariably, the dialog that is presented is at the upper left hand corner of
the primary display. This is especially problematic on systems with multiple
displays.

Expected result:
- I believe we should mimic legacy behavior: in Nav 4.61, the dialog is in the
upper left hand corner of the current browser window, in the body of the
document, with buffer space between its borders and the document borders.

Comment 1

[davidm]

m9

Comment 2

[davidm]

m11

Comment 3

[davidm]

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

Comment 4

[cpratt]

From bug 10722: "Really meant to mark the duplicate the other way around but it
really doesn't matter" - noting this for possible future employee reviews. :)

Marking verified duplicate.

Comment 5

[cpratt]

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

Comment 6

[cpratt]

I don't see a fix in the 1999082016 (M9) build under Windows NT, so I'm
reopening this bug and clearing the resolution. For example, regardless of where
the window is positioned on the screen, all dialogs presented (such as Open
File, Print, or the Wallet dialog) are invariably in the upper left hand corner
of the window. They should be centered in the window instead.

Comment 7

[davidm]

Please file individual bugs against the people that own those windows.
Reassigning this one to law since he owns the find dialog. The code to position
windows is in dialogOverlay.js

Comment 8

[cpratt]

If I understand that comment correctly, I'm to file separate bugs against each
separate window (Wallet, File | Open) that is positioned incorrectly? I can
certainly do so, but I just wanted to make sure I heard you correctly... thanks!

Comment 9

[cpratt]

Where are we at on this?

Another issue: on a Windows 98 multiple monitor system, if you open the
Preferences, it's always displayed starting at (0,0) even if you are working on
a secondary display. That isn't working either...

Comment 10

[davidm]

Sorry I wasn't on the CC list. Yep go ahead and file bugs against every dialog
on the product that doesn't position itself properly. Don't worry about main
windows like Navigator, Composer and Messenger since they will get "special"
positioning based on last position and tiling code. And while you are at file
bugs on every dialog which doesn't have the buttons in the right order on the
different platforms;) I think my code will handle multiple monitors OK ( It
dialog will come up on the same screen as the parent which seems right to me).

Comment 11

[Bill Law]

I've changed the summary to refer to the find dialog explicitly.  I presume
additional bugs have been opened for other dialogs that suffer(ed) the same
deficiency.

Comment 12

[Bill Law]

Moving to M12.

Comment 13

[don]

Not required for beta 1.

Comment 14

[phil]

Would it be possible to make the same find dialog moves away when the found 
occurence is below it (thus being hidden by the box)?

Comment 15

[don]

Move to M16 for now ...

Comment 16

[don]

Move to M21 target milestone.

Comment 17

[Paul Chen]

nav triage team:

Yeah, this is annoying. Marking nsbeta1, p3, reassigning to pchen

Comment 18

[Viswanath Ramachandran]

reassigning to mcafee. 

Comment 19

[Chris McAfee]

Attachment: add call to center dialog

Comment 20

[Chris McAfee]

fixed.

Comment 21

[Blake Ross]

Reopening this for a little UI discussion.  Is the exact center of the document 
really better than in the top left, out of the way of the document (where it 
can't obscure as much of it)?

Comment 22

[cpratt]

As far as I'm concerned, yes, but I'm no longer working on this project. 
Changing QA Contact. Claudius, if you're the wrong guy, please reassign, thanks!

Comment 23

[Chris McAfee]

opening a dialog at (0,0) is a poor UI.
4.7 doesn't do this, MS Word doesn't do this,
in fact I can't think of an app that *does* do this.
Note that windows was opening at ~(30,30) instead of
Linux's (0,0).

The find dialog should remember the location if it was
moved, 4.7 does this, and is a good solution to this problem.
Going back to fixed, we should file a bug for the location
persistance if people agree that's a good idea.

Comment 24

[Claudius Gayle]

To speak to blake's concern yeah, I think if we couldd be real smart and find the top-left of the
viewport(content area, not the screen) that would be ideal, but I'm fine to let this go with just
centering it, as long as we get a new bug for the persistence of the positioning like mcafee said.
Who would be assigned such a bug?

Comment 25

[timeless]

i think the buffer should be about 4en from-left and 6.5en from-top

Comment 26

[Simon Fraser [no longer active]]

This is lame. The find dialog does persist its position if you take out the 
change that mcafee added to call moveToAlertPosition().

Comment 27

[Simon Fraser [no longer active]]

Patch to take out alert positioning, which didn't do the correct thing anyway (on 
Mac, the Find dialog came up somewhere to the right of the center of the browser 
window).

Index: mozilla/xpfe/components/find/resources/finddialog.js
===================================================================
RCS file: /cvsroot/mozilla/xpfe/components/find/resources/finddialog.js,v
retrieving revision 1.18
diff -b -u -2 -r1.18 finddialog.js
--- finddialog.js	2001/04/01 12:09:08	1.18
+++ finddialog.js	2001/04/11 07:20:27
@@ -43,5 +43,5 @@
 
   // Move dialog to center
-  moveToAlertPosition();
+  // moveToAlertPosition();
 }
 

Comment 28

[Simon Fraser [no longer active]]

Attachment: Better fix

Comment 29

[Simon Fraser [no longer active]]

That last patch has the best of both worlds; if the dialog is coming up for the 
first time, ensure that it's sized correctly, and then move it to the alert 
position, otherwise rely on persistence to provide the position.

See bug 75649 for the reason to call sizeToContent().

r/sr please.

Comment 30

[Simon Fraser [no longer active]]

This fix also requires removing the explicit screenX and screenY in the window 
tag of finddialog.xul:

-  screenX="24" screenY="24">

(this is part of the patch in bug 75487).

Comment 31

[Simon Fraser [no longer active]]

I fixed this, together with bug 75649.

The find dialog should now come up in the default alert position (over the parent 
window), only the first time that you bring it up for a profile. On subsequent 
occasions, its position should be remembered (modulo bug 75657).

Comment 32

[Simon Fraser [no longer active]]

Fixed.

Comment 33

[sairuh (rarely reading bugmail)]

vrfy fixed using 2001.04.19.08 comm bits on Mac and 2001.04.19.09 comm bits on
winNT. tested using a new profile: Find in Page dialog appears horizontally
centered and a bit up vertically [by design].

Comment 34

[Boris Zbarsky [:bzbarsky]]

This is not working with some windowmanagers (eg fvwm2, see bug 77148) in Linux.
 It apparently works with other windowmanagers....

Comment 35

[sairuh (rarely reading bugmail)]

yeah, positioning doesn't persist for me using sawmill [ie, the wm settings
prevail].

Comment 36

[Boris Zbarsky [:bzbarsky]]

My apologies for the spam.  Apparently the problem I am seeing is bug 35569.