266338 - Better (more visible) indication of when Find has wrapped or will wrap

Status: NEW

(Toolkit :: Find Toolbar, defect, P3)

Description

[David A. Cobb]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041024 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041024 Firefox/1.0

If I try to find a word on the current page, I get no indication when the search
wraps and re-examines the same set of occurrences I've already seen.  
Doing this, as I did tonight, with a list of 500 Bugzilla reports means wasting
a lot of time looking at what might be duplicates but are really the same thing
I looked at already.

I would prefer to put the effort into examining the problems rather than
fighting with my tools!

Reproducible: Always
Steps to Reproduce:
1. Pull down a large web page -- example: Thunderbird bugs changed in past week.
2. Search for some word you see does occur.
3. Repeatedly findNext.

Actual Results:  
The occurrences are highlighted (this is correct behavior).  So long as you keep
selecting findNext, the search will cycle through the occurrences.

Expected Results:  
Upon arriving at the point on the page where the search/findNext sequence began, 
the search should signal "All Occurrences Shown" or something like that.

At the end-of-page, the search should ask "Do you want to continue the search
from the top?"  NOTE: This second is the simple way, the first is doubtless more
difficult but would really be neater!

Comment 1

[Jesse Ruderman]

The find bar already says "Reached end of page, continued from top", but this is
a subtle change, and I often don't see it.  To make it more clear that Find has
wrapped or has reached the end of the page, Firefox should do some combination of:

A. Show a dialog.

B. Change the color of the find bar textbox (something other than white).

C. Change the color of the selection (something other than green).

D. Upon hitting the end of the page, show the "Reached end of page" message in
the Find bar, but don't continue from the top until I "Find Next" again.  (This
way, nothing or little else on the screen will change, so I'll be more likely to
notice the "Reached end of page" message.)

My favorite solution is D.

Comment 2

[David A. Cobb]

Well, FWIW, I'd vote 'A'.  If I'm searching thru a text, /my/ focus is on the
text - not on the search bar.  If 'D' is better, please make it 'Ding!' --
non-motion may or may not be noticable given that some documents have a load of
duplicated or similar text.

Comment 3

[Nickolay_Ponomarev]

I vote for B+D, but see also bug 259725

Comment 4

[Lisa]

I'd vote A, but based on the reception I've received in commenting on bug 279014
(https://bugzilla.mozilla.org/show_bug.cgi?id=279014), it's clear that dialog
boxes are *not* supported by the firefox development community (excuse my sarcasm).

I would also vote for a sound of some sort (the notfound wav or something like
it) or for option D.

Actually it might not be a bad idea to implement multiple options in concert.
For example, implement both D and B, so that you get an indication that wrap has
occurred once when it first happens (the pause) and a continuing reminder while
search continues.

One of the problems with the "reached end of page" announcement is that it is
only displayed once, when search starts over at the top. Once you hit F3 again,
the notification goes away, so if you miss it the first time, that's it. You
have no continuing indication that you are re-searching. Your loss.

Comment 5

[Jesse Ruderman]

E. Play a sound, either the not-found sound or another sound.

For my own reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=237948#c14 and
https://bugzilla.mozilla.org/show_bug.cgi?id=237948#c19 have interesting
arguments but no ideas that aren't already in this bug.

Comment 6

[Tuukka Tolvanen (sp3000)]

Attachment: ugly demo hack for B+D

findBar.js hack for B+D. Uses the existing strings in the wrong context,
implements no-wrap by searching once in reverse, etc. Might be useful for
testing the suggested behaviour, though.

Comment 7

[Lisa]

(In reply to comment #6)
> Created an attachment (id=172188) [edit]
> ugly demo hack for B+D

I can verify it works on FF1.0 milestone. When it reaches the last entry, if you
hit ctrl-g or F3 again, it will stay at that entry, highlight the findbar form
field in red, and say "reached end of page." next time you hit F3 it will return
to the top of the page.

When findbar is open and you hit F3 after reaching the last entry, the page will
"jump" because it returns to the top of the page for a split second, then does
"find previous" and goes back to the bottom again. Flicker is a fraction of a
second. When findbar is not visible and you are using F3, the flicker does not
occur.

For those interested it would probably be a simple matter to add one line to the
code to all for playing the notfound wav. Though I don't know what the exact
code is so I can't do it.

Comment 8

[jp347]

I have this problem too.  I don't think a sound is the solution (at least not on
its own), as places like libraries and schools don't allow sounds.

I like option D, but would prefer to have C (or both), so that it highlights the
word in yellow the first time it finds it after wrapping.  This would give a
clear indication that it had wrapped when you are only looking at the text.

Comment 9

[Kevin Brosnan]

*** Bug 220849 has been marked as a duplicate of this bug. ***

Comment 10

[Robert Chapin]

I am in favor of a BEEP!

Comment 11

[Chris Wood]

The extension Find Toolbar Tweaks (https://addons.mozilla.org/en-US/firefox/addon/2585) fixes this by highlighting the search field itself yellow after wrapping. I think highlighting the words on the page would be better though.

Comment 12

[Michael Lum]

Option F

Add a check box at the bottom, the same as "Match case" that
says "Don't wrap".

Comment 13

[Brent Jackson]

That sounds great to me.  I never want it to wrap - in fact I cannot see any likely scenario in which anybody would ever want it to wrap - so my ideal solution would be a configuration option to turn this behaviour on or off.

However, given the lack of progress on any solution to this problem (and it IS a problem), a "Don't wrap" Check box would be most welcome.

Ideally, Firefox should "remember" this setting so that it defaults to the same behaviour as the previous search.

Cheers,
Brent.

Comment 21

[Mike de Boer [:mikedeboer]]

So I wrote this thing this afternoon: https://vimeo.com/162972088

What do you think? (n-i Stephen specifically, but please feel free to comment here!)

Comment 22

[Mike de Boer [:mikedeboer]]

Attachment: Patch as shown in the video

Comment 23

[Roman Tarasiuk]

The approaches which are possible to use is described here:
http://superuser.com/questions/472039/no-wrap-when-using-find-toolbar

I have modified 1st of them:


@keyframes blinker {
  50% { opacity: 0.0; }
}

.findbar-container .find-status-icon[status="wrapped"] {
    display: none;
}
.findbar-container .find-status-icon[status="wrapped"]
    ~ [anonid="find-status"].findbar-find-status {
    /* font-weight: bold; */
    font-family: 'courier new';
    padding-left: 50px;
    padding-right: 50px;
    /* font-size: 14pt; */
    background: green;
    color: white !important;
}
.findbar-container .find-status-icon[status="wrapped"]
    ~ [anonid="find-status"].findbar-find-status:before {
    content: '-- Reached end of page -- ';
    background: black;
    font-size: 24pt;
    animation: blinker 250ms linear infinite;
}
.findbar-container .find-status-icon[status="wrapped"]
    ~ [anonid="find-status"].findbar-find-status:after {
    content: ' -- Reached end of page --';
    background: black;
    font-size: 24pt;
    animation: blinker 250ms linear infinite;
}


Put this styles (text above) to the file 'chrome/userChrome.css' in your Firefox profile (%APPDATA%\Mozilla\ - e.g. C:\Users\USER_NAME\AppData\Roaming\Mozilla\Firefox\Profiles\PROFILE). If directory 'chrome' doesn't exist in your profile, you have to create it.
Restart Firefox. Enjoy!

Comment 24

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 24 weeks.

Comment 25

[Markus Keller]

(In reply to Mike de Boer [:mikedeboer] from comment #21)

So I wrote this thing this afternoon: https://vimeo.com/162972088

What do you think?

Looks great, please release :-)

In the meantime, I've simplified & beautified comment 23 to the version below. Note that in recent versions of Firefox, you also have to enable this about:config option: toolkit.legacyUserProfileCustomizations.stylesheets to make the PROFILE/chrome/userChrome.css work.

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

@keyframes blinker {
  50% { opacity: 0.0; }
}

.findbar-container .find-status-icon[status="wrapped"] {
    display: none;
}
.findbar-container .find-status-icon[status="wrapped"]
    ~ [anonid="find-status"].findbar-find-status {
    padding-left: 50px;
    padding-right: 50px;
    vertical-align: top;
    /* font-size: 14pt; */
    background: green;
    color: white !important;
}
.findbar-container .find-status-icon[status="wrapped"]
    ~ [anonid="find-status"].findbar-find-status:before {
    content: '-- Wrapped --';
    padding-left: 10px;
    padding-right: 10px;
    margin-right: 10px;
    background: black;
    font-size: 24pt;
    animation: blinker 250ms linear 4;
}

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates and 25 votes.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 27

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 28

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.