60618 - Find in This Page: Dialog or Window?

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, defect, P3)

Description

[Adam]

11/17 trunk, NS6 - The Find in This Page "dialog" doesn't behave like a dialog.
In a dialog, after pressing OK, the dialog should be dismissed. With the FiTP
dialog, pressing OK does nothing. The text you've entered is located (if found)
but the dialog remains. This completely eliminates the need for "Find Again" as
you have to choose "Cancel" to get the dialog to go away (or, more often than
not, just move the dialog behind the browser window). This seems to be bad
functionality. It behaves like a window (always present until you specifically
choose to close it) but doesn't contain the proper widgets. And you can't switch
to other open windows via the Tasks menu (behavior displayed by dialogs).

If the "Find in This Page" feature is something that is always supposed to be
present and used fruequently (and in lieu of "Find Again") then it should be a
window (similar to CodeWarrior 6). If not, then it should be a dialog that is
dismissed when you choose OK, as well as when you choose Cancel, allowing you to
use the "Find Again" option as it was intended to be used. Either way, its
behavior should be consistent with other dialogs/windows.

Comment 1

[Jesse Ruderman]

On Windows, the dialog isn't modal, and I can switch to other Mozilla windows 
using the tasks menu.  I see "find in this page" on the tasks menu, though, 
which is a little strange (I just filed that as bug 60637).  If "find in this 
page" is modal on Macs, please file another bug for that (or is that bug 
55693?).

On Windows, I see a "Find" button and not an "OK" button.  If Macs have an "OK" 
button, that's probably also a bug.

"Find Again" is useful because it lets you do repeat finds without having the 
dialog in the way.  That feature isn't very discoverable, though.. you have to 
use Ctrl-F, *click find*, cancel the dialog, and then use Ctrl-G.

I'm not sure what you mean by "it should be a window and not a dialog".  Maybe 
that distinction is more clear on macs.

Reassigning to User Interface: Design Feedback, because I think the behavior 
you don't like is intentional.

Comment 2

[Matthew T (active 1999-2002)]

Jesse, a dialog has labelled buttons for dismissing the window (such as `Ok' and 
Cancel), and no close box. A window, on the other hand, has a close box, but no 
labelled buttons for dismissing the window. This visual difference helps you tell 
whether you need to deal with the window/dialog immediately before doing anything 
else. Yes, the distinction is usually more clear on Macs, because Windows dialogs 
often include a close box when they shouldn't (see bug 50521 for fixing that in 
Mozilla).

Ultimately the solution for this is to turn Find into a toolbar or a windoid, but 
for now this is one of the things I mentioned in my spec for bug 7930.

Comment 3

[Zach Lipton [:zach]]

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

Comment 4

[Casey Perkins]

Another issue is that the find dialog should be able to be dismissed (canceled)
with Escape just as other dialog boxes. Or should that be another bug?

Comment 5

[Jesse Ruderman]

Esc cancels Find in This Page (on Win98) as the dialog has focus.  It might 
make sense to make esc cancel it even if I've blurred the dialog by clicking 
elsewhere on the page, though.

Comment 6

[Adam]

I don't think this would work on the Mac - if the windoid(?) is not currently 

active, there's a good chance it will be behind one or more browser windows (not 

sure how it works on Windows).



Dismissing the thing with the Escape key should be a separate bug.



IMO, this bug is only about deciding and implementing a specific behavior (look 

and feel) for the Find windoid. It should either be A) a window (with the 

appropriate titlebar widgets) that remains open until the user specifically 

clicks the close widget, or B) a dialog that is automatically dismissed when the 

user presses one of the buttons (OK or Cancel or Find or whatever).



Examples of a Find dialog would be Netscape Communicator 4.x (choose Edit -> 

Find, enter search criteria and press Find or Cancel and the dialog is dismissed 

and search performed). Examples of a Find window would be CodeWarrior Pro 6 

[choose Search -> Find..., enter text and search, window is moved to background 

(but not closed) and search performed].

Comment 7

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 8

[u12624]

Win98 Moz2001030804
The FITP box *looks* like it has focus after pressing enter for the "The text
you entered was not found." alert box (after finding the last copy) (wrap around
disabled). It doesn't.

Reproduce: Ctrl+F, type in "foo", press enter. It finds it in the previous
sentence. Press enter again, the "not found" alert box comes up. Press enter to
close it. The FITP box looks like it has focus, but it doesn't - no keys work on
it. Alt+Tabing out and back again gives it focus.

Expect: actually give the FITP box focus after the alert box is closed.

Comment 9

[Jesse Ruderman]

jeandre: that focus problem is bug 54936.

Comment 10

[Avi Rappoport]

I think it looks a lot better in v.09 than v.08, but I can still open two copies
of the dialog, which doesn't help.  The old one doesn't work even if I type in
known good strings.  If I hit command-F and there's an open Find Dialog, please
take me there with the find text selected.  If I press Return, go ahead and find
again (please do not delete the text!)

Comment 11

[Michael A. Sypes]

Using Mac OS 8.6
Build ID 2002012103 keeps spawning defective "Find in Page" dialog boxes.
The boxes have neither "OK" nor "Cancel" buttons.
Hitting Return finds the text, but there's no way to dismiss the box.
Hitting Cmd-F creates a new "Find" dialog.

Cross posting to bug 88827

Comment 12

[Michael A. Sypes]

Error in my previous post: Crossed to bug #101576, not 88827

Comment 13

[Jonas Jørgensen]

.

Comment 14

[sfelshin]

I agree that Find in this Page should be either a dialog or a window, and not
some misbegotten confusing blend.  In case anyone is counting votes, I'd like to
see it as a dialog; I think it should behave just like the Find feature in
Netscape Communicator 4.7.

Comment 15

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 16

[Wayne Mery (:wsmwk)]

finishing Simon's WONTFIX