Suppose you try searching (Ctrl+F) for a keyword that has some instances on a long page. Mozilla scrolls through the document and finds one instance. Now enter a new keyword in the find menu: search initiates from the point where the last find stopped. This is confusing and count-productive. It's confusing because most users won't think to press "backwards" because they aren't aware that the previous part of the page has been not searched. It's count-productive because it you can't avoid the steps of finding again the already found instances (since there isn't "circular" operation for the Find feature) It would be better when any change is made in the Find textbox, search to begin from the start of the page, unless a circular mode of operation will be implemented (when reaching end of page, ask to start from the beginning of the document). This is consistent with the way word processors work (not only the MSWord). Maybe it's an rfe, because NS4 behaves in the same way as Mozilla.

Confirming, setting as enhancement.

But when you want a search to begin midway? Sometimes I will click at the middle of a page, because I want 'Find' to ignore search terms above where I clicked... Some sort of compromise?

Well, I see your point. It's a "power user" trick that most average users won't even know abut, otoh I woulnd't dare to say it's useless at all. So, I think we may want to avoid both: a. erroneous search results (because users might not be aware that a new Find starts where the previous Find stopped) b. inability to search from anywhere in the document There doesn't seem to be any means to have both a and b cases avoided except by including a "No text found, do you want to continue from the start of the document?" (only when failed Find didn't start from the beginning of the document). If there aren't any other ideas and this bug will be marked wontfix, then I will file the above rfe as a separate bug. BTW, IE's behaviour is horrible in that aspect: sometimes it starts the new Find from the top of the page, sometimes it doesn't. By single or double clicking on a word of the page, sometimes it resets Find to the start of the document, while occasionally starts searching from the point of the click.

I was going to create a bug report for an enhancement when I first saw that bug. As it is related I was going to put my RFE here. Reading it suggested me another comment: To solve the restart problem mentioned by Dimitrios), a solution may be to use a emacs like way of searching, reacting to character typing (with I guess a sort of history of first encountered position for each sub-word of the search). But this change the way Mozilla currently works. Otherwise, and to come back to my initial enhancement proposal: add a shortcut for 'Home' and 'End' in the Find dialog box. This would bring the 'search cursor' (I guess there is one) up or down, every search starting where this cursor is. As It is one way of solving the bug, I put my comment here. If somebody thinks it should be reported separately, please warn me, and I will report a new bug/rfe.

The problem with starting from the top of the document as soon as the search term changes is that I may want to find the first occurrence of "b" after "a". So right now I search for "a", then for "b". Resetting to automatically search from the top would annoy me to no end. IE for Mac addresses this by adding a Search from Top checkbox to the Find dialog. I don't think you can get much more simple or obvious than that.

adding the checkbox for "start from top" would be cool... marking p5, future, and helpwanted

This works for me. It's a bunch of back-end changes to the find code, and an additional checkbox on the browser Find dialog.

Spoke too soon. Try searching for "SetStart" in the patch a couple of times, then check Start From Top. It doesn't work. Obviously I'm not resetting things properly. Who can provide input on this fun stuff?

Note that I was under the impression that nsIWebBrowserFind.idl was frozen.

Even for adding a single flag, that defaults to the current behavior? Well, there goes my idea.

It's not designated frozen in the idl file...jud?

ahhh, joy, the whole question of file level or iface level freezing. I'm going to avoid that question right now and just point out that pracitically speaking, if you're looking at an idl file who's iface is frozen, and you see #defines in there, you're going to assume they're usable too. We need to push these out of the idl.

Freezing it is bug 99613 which is about to go in. Since I think this attribute is a useful feature, maybe it should go in before freezing.

What does 'start at top' mean if you are searching backwards? How does 'start at top' behave if you are searching through multiple frames? I'd like to see the interface be internally consistent before freezing it.

If you're searching backwards, Start From Top will still reset to the top of the page, which essentially means that you're searching from the bottom of the page. Start From Top (in theory, since it doesn't seem to be working completely) takes you to the start of the root frame, so basically the top-left of the document.

> which essentially means that you're searching from the bottom of the page That's what I would expect. As long at that's commented in the API, the UI can interpret this however. I would think a checkbox which dynamically switched from "start at top" to "start at bottom" depending on the state of the "search backwards" checkbox would be good.

I'd like to get the "startFromTop" attribute into nsIWebBrowserFind before it's frozen. See bug 99613. If this isn't going to be done soon, I could add the attribute, comment it as NYI in the API, and freeze it.

Agreed. We can always figure out the exact UI a little (but not much) later. Should we make this bug about the API change and then spin off a bug for the UI?

Just a comment that might help. I started to use find in the middle of a page. Used it to find the last instance of a word on a page. I wanted to check for any earlier instances os I used the thumb on the scroll to move back to the top of the page and pressed 'Find' again. Result was not found. While this is technically correct it was confusing. I had to click in the page to get the search to start where I expected. Should Find start the search from the top of the visible text on the screen?

trudelle to triage

mass moving open bugs pertaining to find in page/frame to pmac@netscape.com as qa contact. to find all bugspam pertaining to this, set your search string to "AppleSpongeCakeWithCaramelFrosting".

Re: comment #16: If you selected start from top, search backwards, but *not* wrap around, what would you expect to happen? I think our current implementation is also inconsistent in its use of an invisible 'find caret'. I understand starting at the selection if there is one, but how are users supposed to intuit a model that includes an invisible caret? In fact, this is one way that Mozilla differs from NS4.x and IE6, which both start searching from the selection, if there is one, but if not they *always* start from the top, and in any case *always* wrap. I think that is a much better model. For completeness, I note that Opera uses the invisible find caret too, but always wraps. cc marlon for UE input: Are users missing occurrences due to this behavior?

Peter: the same thing. It will start from the bottom of the page. See comment 17 for an idea about the UI. I'm sure there are other ways of representing this as well. Are you sure about 4.x not having an invisible find carrot? I don't have it installed anymore, but I'm pretty sure that if I clicked in the middle of a page and then searched for a word that only appeared above where I clicked, it wouldn't be found. That's why I got into the habit of always srolling to the top and clicking before searching.

I saw comment #17, but don't I want to simplify this, not complicate it further. My point was that wrapping while 'wrap around' is unchecked would be inconsistent, which is another reason I think we should lose that checkbox and always wrap. And yes, I checked the behavior of 4.x, IE6 and Opera before commenting (and checked 4.x again just now to be doubly sure ;-)

From <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=122765#c3">this comment</a>, I think the invisible find cursor is very confusing. I am always clicking in browser windows; usually to remove the focus from a form or another window. I think IE6 does find almost perfect. If there is text selected, they start just after the selection. Otherwise they start from the top. All finds use that logic since a find selects the text it finds. To restart a find from the top, you cancel out of the find dialog, click on the page to unselect, and then ctrl-f to search again. Sometimes I think it would be nice to have a 'Start from top' choice, but I think you might lose more than you gain by having it. Finding "up" without anything selected starts from the bottom of the page. It's wrong to say that it starts at the top since IE6 doesn't wrap. It is a special case. The one thing that kinda bugs me is that IE6 finds never wrap. I like to have the choice like in Mozilla. I think you lose a lot of functionality if you always wrap. Personally, the only reason I ever use the wrap function in Mozilla is to get around the invisible cursor! Just for the record, IE6 doesn't remember settings between finds (it does remember the last phrase searched). Mozilla currently does. I'm not sure I want 'Search backwards' (or others) sticking between uses. Maybe so. With frames, I think IE just searches them in the order they appear in the html file. Just thought I'd get this out there since I've been having particular problems with find today.

That basically jives with what Peter suggested. I don't think it would be too difficult to implement, either.

Mass moving all of my open Nav/toolkit bugs to new owner.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420