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.

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.

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.

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...

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?

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.

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].

updating to new owner. sorry for the spam.

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.

jeandre: that focus problem is bug 54936.

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!)

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

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

.

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.

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".

finishing Simon's WONTFIX