87037 - [Find] Find a new item should reset to the start of page

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, enhancement, P5)

Description

[Dimitrios]

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.

Comment 1

[Tom Mraz]

Confirming, setting as enhancement.

Comment 2

[Gabriel Seah]

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?

Comment 3

[Dimitrios]

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.

Comment 4

[Jerome Lacoste]

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.

Comment 5

[:deanis74]

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.

Comment 6

[sairuh (rarely reading bugmail)]

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

Comment 7

[:deanis74]

Attachment: take 1

Comment 8

[:deanis74]

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.

Comment 9

[:deanis74]

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?

Comment 10

[Simon Fraser [no longer active]]

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

Comment 11

[:deanis74]

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

Comment 12

[Blake Ross]

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

Comment 13

[Judson Valeski]

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.

Comment 14

[Conrad Carlen (not reading bugmail)]

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.

Comment 15

[Simon Fraser [no longer active]]

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.

Comment 16

[:deanis74]

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.

Comment 17

[Conrad Carlen (not reading bugmail)]

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

Comment 18

[Conrad Carlen (not reading bugmail)]

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.

Comment 19

[:deanis74]

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?

Comment 20

[John T Ryan]

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?

Comment 21

[sairuh (rarely reading bugmail)]

trudelle to triage

Comment 22

[sairuh (rarely reading bugmail)]

mass moving open bugs pertaining to find in page/frame to [e-mail] as
qa contact.

to find all bugspam pertaining to this, set your search string to
"AppleSpongeCakeWithCaramelFrosting".

Comment 23

[Peter Trudelle]

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?

Comment 24

[:deanis74]

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.

Comment 25

[Peter Trudelle]

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

Comment 26

[blake]

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.

Comment 27

[:deanis74]

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

Comment 28

[Peter Trudelle]

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

Comment 29

[Robert Kaiser]

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

Comment 30

[Robert Kaiser]

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

Comment 31

[Robert Kaiser]

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

Comment 32

[Robert Kaiser]

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

Comment 33

[Robert Kaiser]

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

Comment 34

[Robert Kaiser]

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

Comment 35

[Robert Kaiser]

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

Comment 36

[Robert Kaiser]

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