341999 - Make auto case sensitivity a toggleable mode

Status: RESOLVED FIXED

(Toolkit :: Find Toolbar, defect)

Description

[Asaf Romano (gone)]

It looks like the fix for bug 340849 also affected the case in which a string is pasted into the findbar textbox.

Without the option to turn off case-sensative search from the findbar UI, the user has to manually lower-case the string.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

My thoughts in bug 342000 comment 3 apply here, as well.

Comment 2

[Peter Kasting]

I'm not sure I understand why the case of pasting a string in should be treated differently than the case of typing a string in.

I'm inclined to think we should decide about auto-case-sensitivity "in general" rather than modifying it for this particular case, which would feel bizarrely inconsistent to me.  So, if it were up to me, WONTFIX.

Perhaps a better question for me to ask is what sort of use cases occur when a user wishes to search for a string in their clipboard, but the string in their clipboard has uppercase characters that they _don't_ wish to match in the current page?  Since that's where this would fall down.

Comment 3

[Mike Connor [:mconnor]]

So, the problem is that if I copy "Without" from the second paragraph, I get a case-sensitive search, but I'm probably looking for the word "without" and not necessarily only the instances where it begins a paragraph.  In that case, Ctrl-F, Ctrl-V, Enter doesn't act as expected, and its annoying to fix once you figure out what happened.

The real problem is that I don't think we can treat FAYT and Ctrl-F the same here, and we need to bring back explicit case-sensitivity in the full UI, and save the clever case for the simple Quick Find.  See beltzner's linked comment for further expansion here.

Comment 4

[Peter Kasting]

Several of us were talking about this at lunch and agreed that this was precisely the problematic use case.  While several crazy solutions were proposed (auto-lowercase anything pasted in from the clipboard; make case-sensitivity turn on in cases where you keyed in a string using the shift key on a character as opposed to cases where the input string is in mixed case), I think those fail the "predictable behavior" test for good UI.

Would it be OK for me to close this WONTFIX (as I'm not going to do anything to fix this particular case in isolation) but reopen bug 340849 to address issues like this in general?  Or morph this into a follup of bug 340849?  Anyone have strong opinions before I go stepping on peoples' toes?

Comment 5

[Peter Kasting]

OK, as I stated on bug 340849, I'm morphing this bug into a bug to make auto-case-sensitivity toggleable between new and old behavior.  More details there.

Comment 6

[Peter Kasting]

On second thought, this might be a bad idea.  Let me hold off on this until the dust settles a little, given the continued discussion on bug 340849, and followup bug 342081.

Comment 7

[Mike Connor [:mconnor]]

Clearing for now, this isn't clear what this is about.  We want the old Match Case checkbox back though, will get a separate bug for that.

Comment 8

[Peter Kasting]

At this point I _think_ this bug is about adding a context-menu item to enable auto-case-sensitivity.

If a match case box returns (which I think may be a mistake, and wouldn't match what other UI people have said about how this should work), I think it should toggle between never and auto (off by default), not between never and always (like the old checkbox).  It should be a set-once-and-forget-it checkbox.  If that is what we go with, this bug can be about that instead.

Comment 9

[Peter Kasting]

OK, at this point this bug is basically in limbo.  We're going to do bug 345786 for Firefox 2.  I consider this bug to be about the Firefox 3 implementation, but no one agrees on what that should be.  See comments/ideas in bug 340849 comment 36.

Comment 10

[Peter Kasting]

My current idea is basically a button whose label is "Match Case: Off" which, when pressed, toggles to "Auto", then "On", then "Off" again.  This could then be used in all modes, and we could do something like light up a light to the left of "Match Case" or something to show when it was in case sensitive mode.  It kinda defies UI expectations a bit, but maybe if we can somehow tie in with how users see pushbutton Power switches or something we can get this right.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

--> Fx3a1

Comment 12

[VanillaMozilla]

You know, you could save yourselves an awful lot of bug reports and patches if you just leave the status quo.  There's nothing unusual or mind-taxing about a case-sensitive search, and the default (not case-sensitive) is fool-resistant.

If that "Match case" option is really causing such anguish (and I don't see any evidence that it is), it's a simple matter to move it right beside the text box where any idiot can see it.  If idiot users don't know what it is for, they probably won't check it, but if they do, they should immediately ly find out what it does.

If you want to save yourselves about 12 bug reports and 6 patches, you could just back out bug 340849 and simplify everything for programmers AND users.  No complicated options that work for some searches and not others.  No new tricks to learn.  Just a simple interface.  What you see is what you get, and your option can be selected with a single keystroke.

Comment 13

[Peter Kasting]

(In reply to comment #12)
> If you want to save yourselves about 12 bug reports and 6 patches, you could
> just back out bug 340849 and simplify everything for programmers AND users.

I don't really understand what this comment is aimed at.

By default we have a Match Case checkbox, which seems to be what you want.  So your problem is...?  What are we going to be getting bug reports and patches on?

Comment 14

[VanillaMozilla]

(In reply to comment #13)
> (In reply to comment #12)
> > If you want to save yourselves about 12 bug reports and 6 patches, you could
> > just back out bug 340849 and simplify everything for programmers AND users.
> 
> I don't really understand what this comment is aimed at.
> 
> By default we have a Match Case checkbox, which seems to be what you want.  So
> your problem is...?  What are we going to be getting bug reports and patches
> on?

Sorry, for some reason I didn't see your reply until now.

OK, let me explain this another way.  There's one overriding principle:  KEEP IT SIMPLE.  A check box is simple.  Three modes, including a complicated auto mode, which is itself subtly and secretly modal, for one binary choice -- is not simple, and it could be darned confusing.  I guess it's OK if you want a user preference in about:config, but I really don't like the idea of the button.  It's too much complexity for a simple choice, and it invites mistakes.

I don't agree with the comment from bug 340849 that "Currently, it's annoying to have to toggle something on to do a case-sensitive search, and annoying to have to remember to toggle it off when done."  It's simple, it works, and what you see is what you get.  The status quo (user determines case-sensistivity with a check box) is just fine, in my opinion, and that would be a fourth mode, in addition to (1) always case-sensitive, (2) auto, and (3) never.

Auto mode seems to me to be a regression in capabilities.  If you're a programmer, with auto mode you can't even search for lower-case variables without also finding upper-case types, and that's exactly the sort of thing you need it for.  And I really don't want that thing to get accidentally toggled.

I strongly suggest just leaving the check box and forget the multi-mode extravaganza.  I am unclear on exactly what has landed in 2.0, so if bug 340849 is already fixed in 2.0, maybe my comment about backing it out doesn't apply.

Comment 15

[Peter Kasting]

(In reply to comment #14)
> I don't agree with the comment from bug 340849 that "Currently, it's annoying
> to have to toggle something on to do a case-sensitive search, and annoying to
> have to remember to toggle it off when done."  It's simple, it works, and what
> you see is what you get.

Then why have we gotten bug reports on search being broken when people forgot to turn it off?  Why have our user observations showed people being confused?  Why have I personally tripped myself with this button when I'm smart enough to understand how it works?  Why have most of the people I work with shared similar sentiments?

> The status quo (user determines case-sensistivity
> with a check box) is just fine, in my opinion, and that would be a fourth mode,
> in addition to (1) always case-sensitive, (2) auto, and (3) never.

No... it wouldn't be a fourth mode.  Whether a user is changing something isn't itself a mode.  The bar is either case sensitive or not, so its search has two modes.  The user can direct the bar to be in one or the other all the time, or to toggle itself automatically, so that choice has three states.  Firefox 2 and trunk have exactly these properties: the checkbox toggles the pref between 0 and 1, and the user can choose to set the pref to 2 via about:config.  All this bug is about is exposing that ability in an easier way than about:config.

> Auto mode seems to me to be a regression in capabilities.

This isn't a bug about whether we should have auto mode.  We have auto mode.  If you believe we shouldn't have it, file a separate bug asking for it to be removed, and argue why.

As you suggested, the right answer is to make things "simple".  Elsewhere, I have proposed moving the case-sensitivity toggle onto a section of the bar which would hold "more options >>", and would be hidden by default (and would remember state, so if you opened it, it would be open next time the bar came up).  This way, fine-grained options like case sensitivity, matching whole words only, etc. could be added to the UI without showing them in most cases where people just don't care.  This would make it pretty hard for you to accidentally get into a mode you didn't want, and pretty unlikely that random users would file complaints at us for options they didn't understand.

> If you're a
> programmer, with auto mode you can't even search for lower-case variables
> without also finding upper-case types, and that's exactly the sort of thing you
> need it for.

Funny how programmers' editors are the applications which tend to have this mode already, then.

> I am unclear on exactly what has landed in 2.0, so if bug 340849
> is already fixed in 2.0, maybe my comment about backing it out doesn't apply.

It's marked fixed1.8.1, which means it is in Firefox 2.

Comment 16

[Peter Kasting]

Whatever gets done for Firefox 3 here is probably not going to done by me, so taking myself off as the assignee.

Comment 17

[Tomasz Kołodziejski [:tomasz]]

We have a "match case" button now so if I'm not mistaken this got fixed.

Comment 18

[Nickolay_Ponomarev]

I agree there's no point in keeping this bug open, but for the reference:

The button/checkbox was added back a long time ago as a 'temporary' solution, this bug was about doing something else with the accessibility.typeaheadfind.casesensitive = -1 mode - see comment 9.