summaryrefslogtreecommitdiffstats
path: root/chrome/browser/autocomplete/keyword_provider_unittest.cc
diff options
context:
space:
mode:
authorpkasting@chromium.org <pkasting@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2008-09-19 22:36:33 +0000
committerpkasting@chromium.org <pkasting@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2008-09-19 22:36:33 +0000
commit9fc8ebd5b437e78b32ac13d570e9d26c18f482b8 (patch)
treeea77edee33c575a8aa9db785a79ab4443f869e60 /chrome/browser/autocomplete/keyword_provider_unittest.cc
parent857218b6d36e1ead540c49c35330b50333085acb (diff)
downloadchromium_src-9fc8ebd5b437e78b32ac13d570e9d26c18f482b8.zip
chromium_src-9fc8ebd5b437e78b32ac13d570e9d26c18f482b8.tar.gz
chromium_src-9fc8ebd5b437e78b32ac13d570e9d26c18f482b8.tar.bz2
Stop exposing manually_selected_match_ outside the AutocompletePopupModel. The main goal of this is to be a first step towards divorcing the popup and the edit from each other.
To do this, I changed the behavior of manual selections. They now do not persist once the user types more characters, hits esc, etc. Our old behavior, which Brett and I designed long ago, turns out to have been a mistake; users who arrowed to an item and then typed more weren't expecting "stickiness" on their previous choice, and it led to user mistakes. This also required changing how we do the "keyword UI" persistence in the case where the user switches into keyword UI, but then deletes all his text. Previously, we used manually_selected_match_ with a provider affinity to the keyword provider in order to accomplish this. Now we stick another flag on the AutocompleteInput, which, when set, biases the keyword provider to return the best results. The user-visible effect of this is that when in keyword UI mode with no query string, the selected entry in the popup will be the first, rather than third, entry. This is a small win. While here I fixed the bug where editing a string and transforming it into a keyword search would avoid switching into keyword UI (as expected), but also delete the keyword off the visible string (oops). I also made us lock the popup once the user changes the manually_selected_match_, in order to give a little more stability to it. I'm sorry this makes so many behavioral changes at once. All this code is tangled together and untangling it is hard :( The keyword-related variables in the AutocompleteEditModel seem a mess. They are probably worse now than before this change; I think I need a followup change at some point to make them all more sane. It seems like we have three variables and complex conditionals where two, and simpler ones, would do. BUG=997976,1201974,1204173 Review URL: http://codereview.chromium.org/3172 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2426 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/autocomplete/keyword_provider_unittest.cc')
-rw-r--r--chrome/browser/autocomplete/keyword_provider_unittest.cc3
1 files changed, 2 insertions, 1 deletions
diff --git a/chrome/browser/autocomplete/keyword_provider_unittest.cc b/chrome/browser/autocomplete/keyword_provider_unittest.cc
index 789667e..f4b50c6 100644
--- a/chrome/browser/autocomplete/keyword_provider_unittest.cc
+++ b/chrome/browser/autocomplete/keyword_provider_unittest.cc
@@ -58,7 +58,8 @@ void KeywordProviderTest::RunTest(
std::wstring AutocompleteMatch::* member) {
ACMatches matches;
for (int i = 0; i < num_cases; ++i) {
- AutocompleteInput input(keyword_cases[i].input, std::wstring(), true);
+ AutocompleteInput input(keyword_cases[i].input, std::wstring(), true,
+ false);
kw_provider_->Start(input, false, false);
EXPECT_TRUE(kw_provider_->done());
matches = kw_provider_->matches();