| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
really painful to add more types, since lots of headers include the
notification service to derive from the notification observer. This splits that
out, so much less of the project should end up including notification_types.h
---Paths modified but not in any changelist:
Review URL: http://codereview.chromium.org/19744
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9020 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
GURL instead of wstring where appropriate. Original patch by phajdan.jr@gmail.com, r=me,sky. See http://codereview.chromium.org/13205 .
BUG=715234
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6758 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
AutocompleteMatch types, and pass a type to the AutocompleteMatch constructor. The added detail in the new types is not used for anything functional; its sole purpose is for metric logging. Someday we could probably update other bits of the code to make use of this, though (e.g. the paste-and-search vs. paste-and-go determinant code).
These are separable changes, but doing either one without the other would have required an annoying number of fragile temporary changes.
Review URL: http://codereview.chromium.org/10855
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5329 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
NULL constructor. It's too easy to forget to set various members with this.
The changes from .resize() to .erase() are necessary because the compiler doesn't know resize() won't be enlarging the vector and thus needing to access the NULL constructor. The changes to the HistoryContents shortcut code were similarly necessary to avoid a NULL construction, but in the end I think made the resulting code a bit clearer.
Review URL: http://codereview.chromium.org/10837
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5271 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
| |
This purposefully does not change the communication interface between the edit and the popup; that's coming in a subsequent pass. As a result, right now the popup isn't really much simpler. That should eventually change.
Review URL: http://codereview.chromium.org/6596
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3113 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1363 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
|
