Find-in-page should not ding while deleting characters.

Find-in-page should not ding while deleting characters.

BUG=18120
TEST=Open google.com, type Ctrl+F, type in garbage. Erase one letter at a time and there should be no beeping while you erase. Try it again, but this time use shift-delete to cut a few letters off the end. It should not ding. Now Copy the whole find string, press Esc, open Find again and on Paste it should not ding.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=30092

[Finnur, 2009-10-23 22:31:14]

Easy one. And dear to your heart. :)

[Peter Kasting, 2009-10-23 22:40:58]

LGTM

http://codereview.chromium.org/338005/diff/3001/4001
File chrome/browser/find_bar_controller.cc (right):

http://codereview.chromium.org/338005/diff/3001/4001#newcode126
Line 126: if (last_search.substr(0, last_search.length() - 1) != current_search)
Edge case: What if we're deleting multiple characters at once (e.g. with
shift-select and then delete)?  Should we ding then?

http://codereview.chromium.org/338005/diff/3001/4003
File chrome/browser/tab_contents/tab_contents.h (right):

http://codereview.chromium.org/338005/diff/3001/4003#newcode1115
Line 1115: // The second to last string we searched for.
Nit: Might be clearer as "The string we searched for before |find_text_|."

[Finnur, 2009-10-23 22:51:08]

Good point. Uploaded.

On 2009/10/23 22:40:58, Peter Kasting wrote:
> LGTM
> 
> http://codereview.chromium.org/338005/diff/3001/4001
> File chrome/browser/find_bar_controller.cc (right):
> 
> http://codereview.chromium.org/338005/diff/3001/4001#newcode126
> Line 126: if (last_search.substr(0, last_search.length() - 1) !=
current_search)
> Edge case: What if we're deleting multiple characters at once (e.g. with
> shift-select and then delete)?  Should we ding then?
> 
> http://codereview.chromium.org/338005/diff/3001/4003
> File chrome/browser/tab_contents/tab_contents.h (right):
> 
> http://codereview.chromium.org/338005/diff/3001/4003#newcode1115
> Line 1115: // The second to last string we searched for.
> Nit: Might be clearer as "The string we searched for before |find_text_|."

[Peter Kasting, 2009-10-23 22:55:33]

http://codereview.chromium.org/338005/diff/5001/6001
File chrome/browser/find_bar_controller.cc (right):

http://codereview.chromium.org/338005/diff/5001/6001#newcode127
Line 127: last_search.substr(0, current_search.length()) != current_search)
Nit: An easier way is:

if (last_search.find(current_search) != 0)

But I'm not sure this is the desirable behavior.  My question in the last review
wasn't rhetorical.

[Finnur, 2009-10-25 02:33:52]

jshin: Over the weekend I started thinking about this patch some more, and got
worried that this might not work on some Asian locales, due to how they input
characters. Can you comment on whether this approach is sound?

pkasting: I'm not sure what you mean by the 'rhetorical' comment. I think what
you suggested was an improvement, so I implemented it. Are you saying I
shouldn't have?

On 2009/10/23 22:55:33, Peter Kasting wrote:
> http://codereview.chromium.org/338005/diff/5001/6001
> File chrome/browser/find_bar_controller.cc (right):
> 
> http://codereview.chromium.org/338005/diff/5001/6001#newcode127
> Line 127: last_search.substr(0, current_search.length()) != current_search)
> Nit: An easier way is:
> 
> if (last_search.find(current_search) != 0)
> 
> But I'm not sure this is the desirable behavior.  My question in the last
review
> wasn't rhetorical.

[Peter Kasting, 2009-10-26 07:42:58]

On 2009/10/25 02:33:52, Finnur wrote:
> pkasting: I'm not sure what you mean by the 'rhetorical' comment. I think what
> you suggested was an improvement, so I implemented it. Are you saying I
> shouldn't have?

I'm just saying _I_ wasn't sure it was an improvement.  Maybe it is, though.  If
you think it is I'm OK with that.

[jungshik at Google, 2009-10-26 19:55:38]

On 2009/10/25 02:33:52, Finnur wrote:
> jshin: Over the weekend I started thinking about this patch some more, and got
> worried that this might not work on some Asian locales, due to how they input
> characters. Can you comment on whether this approach is sound?

I think it's ok for now although this isn't ideal for Korean.

Your patch does not make any worse than it is now (Chrome supports what Firefox
does not support - matching a partial syllable in composition at the expense of
more beeping than Firefox). Moreover, the 'correct' way of using collation-aware
search instead of std::string's find does not work for Korean unless either we
change ICU or we create a custom collation for search. That's because ICU uses 
a single collation table for both sort and search although two different
collation tables have to be used in some locales (Korean, Thai, Japanese, etc).
See http://bugs.webkit.org/show_bug.cgi?id=30646 and
http://bugs.webkit.org/show_bug.cgi?id=30437

Initially, I worried about Thai,too  but I was wrong.）
 
Afaict, Chinese and Japanese are all right, too because currently FiP doesn't
(seem to) deal with a character/characters not yet committed for C+J input
methods (while it does for Korean Hangul). 


> pkasting: I'm not sure what you mean by the 'rhetorical' comment. I think what
> you suggested was an improvement, so I implemented it. Are you saying I
> shouldn't have?
> 
> On 2009/10/23 22:55:33, Peter Kasting wrote:
> > http://codereview.chromium.org/338005/diff/5001/6001
> > File chrome/browser/find_bar_controller.cc (right):
> > 
> > http://codereview.chromium.org/338005/diff/5001/6001#newcode127
> > Line 127: last_search.substr(0, current_search.length()) != current_search)
> > Nit: An easier way is:
> > 
> > if (last_search.find(current_search) != 0)
> > 
> > But I'm not sure this is the desirable behavior.  My question in the last
> review
> > wasn't rhetorical.

[Finnur, 2009-10-26 21:01:05]

Thanks to both of you.

Peter, while testing this once more after making your suggested change, I
discovered that it wasn't dinging if you closed the Find box, reopened it and
then pasted the same string into it. I just needed to clear the find_string_ on
StopFinding (one liner change).

On 2009/10/26 19:55:38, Jungshik Shin wrote:
> On 2009/10/25 02:33:52, Finnur wrote:
> > jshin: Over the weekend I started thinking about this patch some more, and
got
> > worried that this might not work on some Asian locales, due to how they
input
> > characters. Can you comment on whether this approach is sound?
> 
> I think it's ok for now although this isn't ideal for Korean.
> 
> Your patch does not make any worse than it is now (Chrome supports what
Firefox
> does not support - matching a partial syllable in composition at the expense
of
> more beeping than Firefox). Moreover, the 'correct' way of using
collation-aware
> search instead of std::string's find does not work for Korean unless either we
> change ICU or we create a custom collation for search. That's because ICU uses

> a single collation table for both sort and search although two different
> collation tables have to be used in some locales (Korean, Thai, Japanese,
etc).
> See http://bugs.webkit.org/show_bug.cgi?id=30646 and
> http://bugs.webkit.org/show_bug.cgi?id=30437
> 
> Initially, I worried about Thai,too  but I was wrong.）
>  
> Afaict, Chinese and Japanese are all right, too because currently FiP doesn't
> (seem to) deal with a character/characters not yet committed for C+J input
> methods (while it does for Korean Hangul). 
> 
> 
> > pkasting: I'm not sure what you mean by the 'rhetorical' comment. I think
what
> > you suggested was an improvement, so I implemented it. Are you saying I
> > shouldn't have?
> > 
> > On 2009/10/23 22:55:33, Peter Kasting wrote:
> > > http://codereview.chromium.org/338005/diff/5001/6001
> > > File chrome/browser/find_bar_controller.cc (right):
> > > 
> > > http://codereview.chromium.org/338005/diff/5001/6001#newcode127
> > > Line 127: last_search.substr(0, current_search.length()) !=
current_search)
> > > Nit: An easier way is:
> > > 
> > > if (last_search.find(current_search) != 0)
> > > 
> > > But I'm not sure this is the desirable behavior.  My question in the last
> > review
> > > wasn't rhetorical.

[Peter Kasting, 2009-10-26 21:04:33]

LGTM

http://codereview.chromium.org/338005/diff/1006/2009
File chrome/browser/find_bar_controller.cc (right):

http://codereview.chromium.org/338005/diff/1006/2009#newcode126
Line 126: if (last_search.find(current_search) != 0)
Nit: If you want, you can inline those temps into here.

http://codereview.chromium.org/338005/diff/1006/2010
File chrome/browser/tab_contents/tab_contents.cc (right):

http://codereview.chromium.org/338005/diff/1006/2010#newcode1123
Line 1123: find_text_ = string16();
Nit: Use "find_text_.clear();"