168824 - Typeaheadfind: should preserve case of search string

Status: NEW

(SeaMonkey :: Find In Page, enhancement)

Description

[Darin Fisher]

when searching for a string on a page using typeaheadfind, it'd be really nice
if the status bar displayed the text i've entered without changing the case
(e.g., if i type nsIFileURL, then it shouldn't show "nsifileurl" because that's
less easy to read).

Comment 1

[Darin Fisher]

adding as blocker for bug 30088 per instructions from aaronl.

Comment 2

[Aaron Leventhal]

I have one more thought about this - tell me what you think.

When the user types all the same case, typeaheadfind could search in case
insensitive mode.
When the user types mixed case, this could make typeaheadfind search in
match-case mode.

It may sound strange, but I've seen search implemented that way in other
software, and it works quite well - in terms of guessing what the user wants. It
would a way we could get one step closer to not needing the find dialog.

Anyway, I'm not married to it, just thought this was a good context to bring up
the idea.

Comment 3

[Darin Fisher]

interesting... i for one really like case insensitive search, even though i am
inclined to enter the characters in mixed case (just because that's how i'm used
to typing some strings).

Comment 4

[Jesse Ruderman]

Another possibility is showing the exact case of the *match* after doing a
case-insensitive search.  That's not ideal if you want to be able to show
"searching for 'foo'" while doing a CPU-intensive search through the page.

Comment 5

[Tuukka Tolvanen (sp3000)]

I think case sensitive searching ability would be nice, it does speed up
navigating code a bit sometimes.

Emacs, nearly same as comment 2 method: Typing in all lowercase does
case-insensitive search, any uppercase characters trigger case-sensitive search.

Comment 2 method: Can't search for an all-uppercase word case-sensitively.
Emacs method: Can't search for an all-lowercase word case-sensitively.

Should this bug be about the status bar feedback only, and the case insensitive
search triggering be spun off?

Comment 6

[Aaron Leventhal]

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

Comment 7

[Johan Walles]

Either this bug is about case (in)sensitive searches, in which case it should
have a different summary.

Or it is about preserving the case of the typed search string, in which case bug
183893 is not a duplicate of this one.

Darin, it's your bug, you decide.

Comment 8

[Darin Fisher]

it's up to aaron really.  if he wants to solve both problems with one patch,
then duping the bugs seems reasonable.

Comment 9

[Jo Hermans]

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

Comment 10

[Daniel Wang]

please remember to turn this off is CAP is on

Comment 11

[Aaron Leventhal]

I think we're either going to use Shift+letters for more accelerators or as a
way to use accesskeys.

On the other hand, we could still pay attention to this once the user starts
FAYT manually with / or '.

I won't call it WONTFIX, but it's definitely helpwanted.

Comment 12

[Elmar Ludwig]

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

Comment 13

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 14

[chAlx]

Actually FAYT uses current case sensitivity settings from the Find dialog. So one can tune FAYT options via Ctrl-F and then use it as he wants. Is's not the best ui design (as seen in bug 344422) but it works.

Suggest to close as fixed somewhere in bug 97023.