Closed Bug 279014 Opened 20 years ago Closed 20 years ago

Bring back option for wrap/no wrap when using find toolbar

Categories

(Toolkit :: Find Toolbar, enhancement)

Product:
Toolkit
Component:
Find Toolbar
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: lady.of.dreams, Assigned: bugzilla)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050118 Firefox/1.0+

There used to be an option for wrapping or not wrapping when using the find
dialog box. With the introduction of the find toolbar there is no option at all.
I don't see the point of removing options and thus giving users less of a
choice. I don't care if the option is on the toolbar itself or is a hidden
about:config preference, but something should be there. If the option is placed
on the find bar, the user's preference should be remembered across sessions.

Reproducible: Always

Steps to Reproduce:
1. Open the find toolbar
2. Look for a check box for "wrap"
3. Open about:config
4. Look for a preference pertaining to wrap when using the find bar

Actual Results:  
No option can be found

Expected Results:  
Option should be there
There's no point in adding a preference for the sake of "user choice."  In fact,
there is a much greater benefit in reducing the degree of user choice and
configuration required, and focusing on creating an optimal experience without
configuration.

Unless you can come up with a use-case where this is actually useful/needed,
that's the way it will remain.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
(In reply to comment #1)

> There's no point in adding a preference for the sake of "user choice."  In fact,
> there is a much greater benefit in reducing the degree of user choice and
> configuration required, and focusing on creating an optimal experience without
> configuration.

That is why I mentioned the option for a hidden preference in about:config, so
there could be the option without unduly burdening the average user's program
experience.

> Unless you can come up with a use-case where this is actually useful/needed,
> that's the way it will remain.

It's useful because it provides an indicator that the user has reached the
bottom of the page. You may say that the "Reached end of page, continued from
top" message already does that, but I don't find this sufficient. When I am
doing a word search in a page, the last place I look is in the findbar. I'm
looking at the results that are found. The little bit of text added to the
findbar to tell me I've reached the bottom of the page is not enough to attract
my attention, resulting it unnecessary researching.

You may also say "well, you can tell where you are in the page by the scroll bar
position." My response is the same. The last place I'm looking when I'm doing a
search is the far right side of the window where very little or no text is
likely to be found. The scroll bar position just does not catch my eye.

I would like a more obvious indicator that I have searched the entire document.
My preference is for the option for no wrap. Another option would be a pop up
menu saying "search finished" or something like that, but I don't think you'd
like that because the entire purpose of the findbar is to eliminate big pop up
menus in the middle of the window.
(In reply to comment #2)

Seeing no objections...
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
(In reply to comment #3)
> (In reply to comment #2)
> 
> Seeing no objections...

No, that's not the way it works.  If you convinced me, I'd reopen the bug.

I understand that the reminder is subtle, but I see no compelling reason to add
code to the new find impl to support this.  You want a more obvious indication,
but I don't see an unobtrusive way to provide this, and I don't intend on adding
substandard UI to the app, even if its a buried and hidden pref.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WONTFIX
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > 
> > Seeing no objections...
> 
> No, that's not the way it works.  If you convinced me, I'd reopen the bug.
> 
> I understand that the reminder is subtle, but I see no compelling reason to add
> code to the new find impl to support this.  You want a more obvious indication,
> but I don't see an unobtrusive way to provide this, and I don't intend on adding
> substandard UI to the app, even if its a buried and hidden pref.

I've given you an unobtrusive way. No wrap with an about:config pref. No UI
change, except to possibly remove the "beginning at the top" part of the message
in the findbar. You just won't acknowledge it.

And anyway, this is where we apparently disagree. You call it "obtrusive" but I
would call it simply "visible" or "obvious" as you called it before. What you
call "subtle" I would call "barely enough to even acknowledge its existence." It
can sometimes take a (internet-wise) considerable amount of time to realize that
you completely blew by the "reached end of page" indicator and that you are now
"finding" the same instances that you've already been through. In essence, this
"subtle" indicator is wasting my valuable time by having me repeat myself. A
more "obtrusive" indicator is exactly what it needs, at least for the people who
are interested in it and willing to turn on the pref.

One compelling reason is that there are some people (documented by the reported
bugs and threads in mozillazine) that did not like it when the "wrap" option in
the find dialog box pre-v0.9 switched from remembering your preference to always
being checked. This is the same issue here only even more extreme, because now
we don't have a choice. It's not like the choice was never there. It has been
systematically taken away from us, and for no good reason other than the fact
that some elements don't see that pref as "necessary." Well I'm sure there are a
lot of people out there who don't see every single pref option in FF as
necessary, but that doesn't mean all options should be removed.

It's not like there isn't code for "no wrap." It existed pre-0.9. Why is it such
a big problem just to put it back in, slightly modified to accomodate the new
findbar?
I'm with Lisa on this one. In fact, I'm even worse - I totally hadn't noticed 
that there IS a notifier "reached end of page" in the find bar until I read 
about it here. I've just been pressing F3 and going round and round and round 
in circles. 

Just like Lisa, my focus is on the page, not on the find bar or the scrollbar. I
use keyboard shortcuts for most things, so I just press F3 (or CTRL-G). And I
can find that without my eyes ever leaving the page or moving to the find bar.

Suggestion:
What about changing the behaviour to the way some IDEs (and office apps) work? 
i.e. *not* wrapping by default, but when the end of the page has been reached
giving the feedback "Reached end of page. Press F3 again to search from top". 
That way it CAN wrap, there's NO checkbox, NO hidden option, just user
interaction. And those people who do actually notice the feedback in the 
find bar then also know that pressing F3 again will take them round again. But
for the rest of us, pressing F3 and having nothing happen is an indication that
there's nothing more to look for.
I like comment #6 's suggestion of having a skip in normal behavior to signal an
end of document. Although having a pref would also be nice.

Another beef I have with the find system is that after the timeout (when the
find bar disappears) you can still continue to press Ctrl+G to continue
searching but when it loops the find bar does not pop back open to show the
"looping" message. Instead it loops without any indication other than the scrollbar.
No, the method of enabling it isn't the issue.  Its the UI itself once enabled
that I'm talking about.

Wrap by default and without interruption is the choice we've made.  We're not
going to change core behaviour like this.  We don't want dialogs of any sort, so
those suggestions are out the window.

If someone really wants to implement a different find mechanism, then that's
what extensions are for.
(In reply to comment #8)
> No, the method of enabling it isn't the issue.  Its the UI itself once enabled
> that I'm talking about.
> 
> Wrap by default and without interruption is the choice we've made.  We're not
> going to change core behaviour like this.  We don't want dialogs of any sort, so
> those suggestions are out the window.

You changed it once already. This wouldn't be a change as much it would be a
restoration.

All of us have mentioned ideas that don't involve dialog boxes. One is just to
stop searching (no wrap) and display a message that says "reached end of page."
This behavior has no more "dialogs" than the current behavior. The message can
be displayed in the same location as the "reached end of page, starting from
top" message. Aside from that it's just the difference between starting over at
the top of the page and... not.

One of the other suggestions was just to pause the search for one "ctrl-g" or
"F3" before resuming at the top. No "dialogs." So what's the problem with those
solutions?
 
> If someone really wants to implement a different find mechanism, then that's
> what extensions are for.

You guys broke it by removing it in the first place.
(In reply to comment #8)
...
> Wrap by default and without interruption is the choice we've made.  We're not
> going to change core behaviour like this.  We don't want dialogs of any sort, so
> those suggestions are out the window.

How about playing the "notfound.wav" sound file when it loops? At least there is an auditory indication 
for it. And it kind of makes sense since no more entries are found and you are looping back to the top.
playing notfound is a bad idea, because then it overloads the sound in a certain
sense.  Making it skip a step isn't really any more intuitive, either.  Adding a
pref and more code to simply skip something just doesn't make sense.  I don't
see the value in that.

(In reply to comment #9)
> > If someone really wants to implement a different find mechanism, then that's
> > what extensions are for.
> 
> You guys broke it by removing it in the first place.

We chose a different method, one that has found a great deal of user acceptance.
 Like any decision we've made from the outset, there will always be someone who
wants a different way of doing things.  Instead of maintaining multiple
codepaths and multiple prefs, we've elected to leave alternate ideas like this
to extensions.  You might not agree with how we do things, but that's been the
driving force behind the project.
(In reply to comment #11)
> playing notfound is a bad idea, because then it overloads the sound in a certain
> sense.  Making it skip a step isn't really any more intuitive, either.  Adding a
> pref and more code to simply skip something just doesn't make sense.  I don't
> see the value in that.

It seems we were unlucky and drew the close-minded reviewer? Why did you tell me
to argue my case when you clearly have no intention to take seriously any of our
arguments?
 
> (In reply to comment #9)
> > > If someone really wants to implement a different find mechanism, then that's
> > > what extensions are for.
> > 
> > You guys broke it by removing it in the first place.
> 
> We chose a different method, one that has found a great deal of user acceptance.

Just like the great acceptance that has come with the findbar itself? I don't
know about you, but all I hear about it in mozillazine are gripes. Those may be
the opinions of a minority of people, I don't really know, but it seems all of
these changes for the sake of changes have ruffled more feathers than anything
else, all for the sake of "no dialogs" and giving people only one code path to
"choose from" in the core. Not to mention how buggy the findbar is.
(In reply to comment #11)
> playing notfound is a bad idea, because then it overloads the sound in a certain
> sense.

Well I only selected the "notfound.wav" sound just because it was already there.
If you wanted to you can always create a different wav file for that function.
This is just a minor detail.

And overloading it isn't really a bad idea. There won't be any ambiguity whether
it means FIND_NOTFOUND or FIND_WRAPPED, since FIND_NOTFOUND can only be made
during typing, while FIND_WRAPPED can only be made on the second and subsequent
matches. All in all it is still unique to find-as-you-type and I think it would
be more beneficial to the user to have the same familiar sound rather than to
have a different sound for the user to recognize.

And there isn't a lot of code to it.

==== nsTypeAheadFind.cpp ====
1425:  hasWrapped = PR_TRUE;
1426:  continueLoop = PR_TRUE;

Just insert the line:

==== nsTypeAheadFind.cpp ====
1425:  hasWrapped = PR_TRUE;
1426:  continueLoop = PR_TRUE;
+1427:  PlayNotFoundSound();
(In reply to comment #11)
> playing notfound is a bad idea, because then it overloads the sound 
> in a certain sense.  

Also, I don't usually have the speakers on, anyway.

> Making it skip a step isn't really any more intuitive, either. 

Well, every other app I use that does it that way (off the top
of my head - IntelliJ IDEA, MS Office) seems quite intuitive to me
(but wether something is intuitive is TOTALLY subjective): I'm telling
the computer to do something ("find next") and it reacts in a way that
tells me something about the result of this command ("Sorry, mate - there
IS no next. D'you want to look somewhere else?"), rather than going ahead 
and doing something else ("Hey, there wasn't actually any next down there. 
But look what I found WAY up here! Maybe THAT's what you meant? No? 
Well, too bad. I've scrolled all the way up the anyway now.").

> Adding a
> pref and more code to simply skip something just doesn't make sense.  I don't
> see the value in that.

Ummm... We're just ARGUING the value of it here, aren't we?

> We chose a different method, one that has found a great deal 
> of user acceptance.
>  Like any decision we've made from the outset, there will always be 
> someone who
> wants a different way of doing things. 

I agree - you can't please all folks all of the time. But there
really appear to be a substantial number of people over at
Mozillazine with a number of gripes about the find toolbar.

> Instead of maintaining multiple
> codepaths and multiple prefs, we've elected to leave alternate ideas like this
> to extensions.

The "alternate idea" isn't really alternate. It's "we liked it fine
the way it was. PLEASE put it back."

Also - would an extension allow completely REMOVING the current
find toolbar? Removing all of the FAYT behaviour and key mappings,
remapping F3 and CTRL-G to the new (old) non-subtle behaviour, and  
making the current find toolbar simply NEVER show up? 

I didn't think that was the way extensions worked. If it is, well
then would it be pretty much straightforward for someone
who knows the code and knows extensions to bundle up the previous
version from the existing old sources and bung it into an extension?
I'd also like to point to the discussions in the following Bugzilla 
entries:

https://bugzilla.mozilla.org/show_bug.cgi?id=244438 (Status: NEW, btw)
esp. comment 3

https://bugzilla.mozilla.org/show_bug.cgi?id=237948 (Status: NEW)
esp. comment 19

*** Bug 237948 has been marked as a duplicate of this bug. ***
I'm not closed-minded, I'm confident in what we have, and I haven't had anyone
explain the utility of stopping at the end of a document in any meaningful way.
 "Because I want to know" doesn't explain the utility.  "Because other apps do
it" doesn't either.  If I don't see the value, then explain it to me.  I'm not
infallible, but I need to see the value to add the code.  (Hint: I need X to
solve Y is a good format...)  I may say that Y can be achieved sans pref, or
with a tweak to the default behaviour.  If the solution to Y can be achieved in
a pref-less environment, then that's improving the implemenation for everyone.

In the bug I just duped to this one, someone made the point of "finding the last
entry in a document" although this is a best a trivial step, if you indeed
notice the warning, you can just hit find previous and get back to it.

Right now, at best, some enhancement to the notification of the wrap (either a
sound, or better yet, a bit more obvious visual indication of the wrap) is
probably the only real "fix" for this that makes sense.  That's not a pref,
that's an enhancement for everyone.

As a note on MozillaZine.  There's a lot of useful feedback there, but it has to
be taken with a grain of salt.  You're never going to have someone who likes new
 feature/change X ranting long and loud about keeping it, but someone who's
decided they hate it because of Y will demand that we back out everything
because Y is the most important feature to them because they need it for Z. 
Usually, we have been able to find a way to do Z in such a 

Our success thus far is based on doing things on instinct and intuition,
combined with trying to address feedback within a unified solution.  Making one
solution that works for a wider range of people is better than two solutions
that might work better for a slightly bigger range of people.  I'll expand on
why I think that elsewhere, since its not directly related to the bug itself.
(In reply to comment #17)
> (Hint: I need X to solve Y is a good format...)

Apparently we disagree about whether or not this has been done. I believe I have
already done this:

I need a feature to solve the fact that the "reached end of page" notification
is a wholely insufficient indicator and is extremely easy to miss, thus leading
to repetition and wasted effort.
But of what value is the indicator/knowing you've reached the end of the page? 
You're not taking the next step in your explanation.
(In reply to comment #19)
> But of what value is the indicator/knowing you've reached the end of the page? 
> You're not taking the next step in your explanation.

The value is that 99.99% of the time when I search for a word or phrase on a
webpage, the search starts at the top and works its way down. Why do I need it
to wrap the search if 99.99% of the time the search will have covered the entire
page by default and I have no reason to go back to results that I already saw
and rejected? I would like to know when I reach the end of the page so that I
don't just keep searching and searching, thinking that I'm going though new
parts of the site when in reality I'm re-searching what I've already seen. This
can happen quite easily on pages full of text.

Even if I do want to go through the results a second time, I would like to know
that I am going over already reviewed results rather than previously unseen
ones. I can't speak for other people, but if I were looking for a certain word
or phrase on a page and I wanted to first see how many results there were and
then second go over them again to look at them in more detail, I would certainly
like to know when the initial review has completed and the second round of
reviewing has begun.
So, really, what you're talking about is a better notification, not really a
need to stop.  And if we turn off wrapping, you need to manually go back to the
top of the page, if we were to use the old method you're calling to have
returned.  The old non-wrapping code stops, and you can either search backwards
or manually scroll back up.  That really makes your second example a huge pain.

This is the point I've been trying to make: what you really want is actually
different from the solution you're asking for would give you.  A better
notification would do the trick in that use-case, for most if not all users.
(In reply to comment #21)
> So, really, what you're talking about is a better notification, not really a
> need to stop.  And if we turn off wrapping, you need to manually go back to the
> top of the page, if we were to use the old method you're calling to have
> returned.  The old non-wrapping code stops, and you can either search backwards
> or manually scroll back up.  That really makes your second example a huge pain.

In your opinion. It served me just fine for many months, back when it existed.
It's only a huge pain *if* you want to search again, and 99.99% of the time, I
didn't.

> This is the point I've been trying to make: what you really want is actually
> different from the solution you're asking for would give you.  A better
> notification would do the trick in that use-case, for most if not all users.

No. What I want is exactly what I've been asking for... NO WRAP!! However, I am
a pragmatist (at least some of the time), and if I can't get what I want I will
settle for what I can. If you won't accept my solution, all I can really do is
convince you of my premise, which is that the findbar wrap notification is
insufficient as is and results in wasted effort being expended. The "reached end
of page" notification is so insufficient it may as well not be there at all. In
the absence of a "no wrap" option, I will take just about ANY solution that
works better than the current one. A pause, a noise, some kind of indicator that
has the potential to do what it is meant to do.
OS: Windows XP → All
Hardware: PC → All
Summary: [RFE] Bring back option for wrap/no wrap when using find toolbar → Bring back option for wrap/no wrap when using find toolbar
Version: unspecified → Trunk
(In reply to comment #19)
> But of what value is the indicator/knowing you've reached the end of the page? 
> You're not taking the next step in your explanation.

OK.  Here's a scenario.

I often need to find the last entry or item in a log such as a changes.txt, a
CVS change dump, a chat transcript, that relates to issue X (possibly the module
I'm working on). Or say I have a huge stdout log file which I KNOW led to an
error and I need to find the last exception dump in that and read it. Of course,
along the way, looking for the last (and probably fatal) error, I need to also
check the log for other exceptions. So simple searching "upwards" or "backward"
doesn't cut it - I need a quick scan of the dump in order to know what the
problem is. I press Ctrl-f, search for "Exception" or "Level: Error" or
whatever, jump/read quickly through the document with F3 and once I found the
last entry, I take time to discover what finally went wrong.

Once I've found that, I need to read it, because I need to react to it, respond
to it, fix it, whatever. If FF wraps, simply telling me it has wrapped, then
once it's wrapped I've lost the place and there's no sufficiently easy way to go
back. I'm a keyboard person. Grabbing the mouse, going to the find bar, clicking
on "find backwards" to go back to the previous place is just putting me through
extra unnecessary hassle which wasn't there before. Also, it distracts from my
task at hand, it breaks concentration, it's a change in interaction plan ("find
problems, look for last entry, concentrate on that") that I perceive as an
interruption or a disruption. 

See - that's the cincher: Once the search wraps, it's broken and done away with
what I set out to do and just telling me its done that is of no use at all. I
want/need to prevent it from doing that *before* it does it (or, rather, I need
to stop myself from pressing F3 again), rather than being made to jump through
hoops in order to undo what it's done.

The nature of these logs, dumps, (or JavaDoc documentation, as another example)
is that they look so remarkably monotonous - i.e. just from visual appearance
and just looking at the content of the page there's no quick visual way to tell
that the search has wrapped. When I'm developing or debugging or just browsing I
DON'T look at status bars, control bars, scroll bars, etc. Little things turning
red don't catch my eye. Little messages in the status bar, in a small font,
telling me something, don't register. I'm pretty good with the keyboard, so I'm
not contantly looking at the mouse pointer in order to click "next", etc., and
after all it's the CONTENT I'm interested in, not the can it comes in.

Also, playing a sound would be pretty much useless. I don't have the speakers on
(and I imagine many people in office environments don't).

Just ONE skipping of the "find again" and wrapping, just as suggested in the
Emacs examle in the other bug report, would solve ALL these problems, while
still retaining EVERYBODY's ability to wrap and wrap and wrap again, not adding
any dialogs, not adding any GUI elements, any preferences, etc.
(In reply to comment #23)
> The nature of these logs, dumps, (or JavaDoc documentation, as another example)
> is that they look so remarkably monotonous - i.e. just from visual appearance
> and just looking at the content of the page there's no quick visual way to tell
> that the search has wrapped.

The same can happen with very long websites with lots of text and a generic
background, so this isn't just something relevant to people reading changelogs.

> When I'm developing or debugging or just browsing I
> DON'T look at status bars, control bars, scroll bars, etc. Little things turning
> red don't catch my eye. Little messages in the status bar, in a small font,
> telling me something, don't register. I'm pretty good with the keyboard, so I'm
> not contantly looking at the mouse pointer in order to click "next", etc., and
> after all it's the CONTENT I'm interested in, not the can it comes in.

Not only that, but when the search has wrapped, the notification in the findbar
displays only ONCE, at the exact moment the wrap occurred. Once you hit ctrl-g
or F3 one more time, the notification disappears. So if you happen to miss the
notification the first time, you won't get any new indications that wrap has
occurred unless you happen to notice that you are reviewing already reviewed
results or if you notice the notification the second (or perhaps third or
fourth) time around. Lots of wasted effort there.

> Just ONE skipping of the "find again" and wrapping, just as suggested in the
> Emacs examle in the other bug report, would solve ALL these problems, while
> still retaining EVERYBODY's ability to wrap and wrap and wrap again, not adding
> any dialogs, not adding any GUI elements, any preferences, etc.

While I would personally prefer this option to what we have now, I still would
very much like to push for the no wrap option. Do it with a hidden about:config
pref. Do it with a small check box on the findbar that says "wrap" next to it.
It wouldn't be that obtrusive and it wouldn't be that hard to do (the code is
sitting in old versions of FF--0.8 or below--with just a few small modifications
to accomodate the findbar rather than the old find dialog box). Implement BOTH
solutions while you're at it (no wrap option, or a single pause before wrapping
with the wrap option).

But most importantly, do SOMETHING, because the current situation is just not
cutting it.
See also bug 266338, for making the wrap indication more visible (without adding
a pref).
*** Bug 292062 has been marked as a duplicate of this bug. ***
Heres what I do on a daily basis: 
My company pays for a service that gives all newspaper articles that contain
certain keywords. We get all of them as a single www page on our intranet.
I'm not interested in all of them, so I make search for my keywords.
As you know half of the newspapers have the same articles, so most of the
matches are just dupes or very similar ones. 
Here this bug is truly annoying, as it's not easy to tell that I've seen the
result before. At the same time I have to concentrate on the text, so I don't
want to check the status bar all the time.
Is it sufficient explanation for the need to give this option?
(I don't like the idea of sound, as I have sound disabled by default on my PC)

I could give more examples, searching in PHP manual
(http://www.php.net/get/php_manual_en.html.gz/from/a/mirror) could be one.

Also as someone pointed out, 99 % of the time when you've searched through the
document, you don't want to search again, it's pure nonsense.




*** This bug has been confirmed by popular vote. ***
Ever confirmed: true
Product: Firefox → Toolkit
Sorry folks, this is the silliest bug I've seen in a long while, silly because:

- it wastes significant time for everyone who uses find, concentrates on the text
  to see if any of many similar occurrences is relevant, "hours later" he finds that
  search has wrapped for the umptieth time.

- I don't see any convincing reason why anyone could possibly object to the requested
  configuration option.

- the option was present in versions long time ago


pretty please reopen and fix.
After reading through some more comments it seems that indeed some more convincing is
needed so here's my request:

Firefox should support the use case of finding each match of a given word exactly once.

I hold that this is an extremely common use case and I hold that it is not supported
for anybody who keeps her eyes on the text rather than on the toolbar at the bottom.

Incidentally the easiest way to recognize when all matches have been visited is by going
from top to bottom, that's why hitting the bottom is where most people want to stop
in most cases.

If you want to implement s.t. more sophisticated that serves the same use case; fine.
But it seems most folks commenting here would be happy with the simplest of all solutions:
bring back the option to stop at the bottom.
http://superuser.com/questions/472039/no-wrap-when-using-find-toolbar

It is a combination of design decisions has created a problem for some users.

    Search will wrap upon reaching bottom of page
    No popup/dialogue is show to notify the user
    No sound is played to notify the user
    The Reached end of page, continued from top message only displays until Next is pressed

This combination of decisions forces users to check the toolbar after each search to make sure not to enter an "endless search".
After over a year, I have a solution

http://superuser.com/a/550410
You need to log in before you can comment on or make changes to this bug.