Both the cursor misplacement and having an initial space change the default behavior are bugs. A leading space should not disable a keyboard search.  I would expect a leading question mark to do that, though -- use that as a workaround.

The space is more intuitive! I never actually looked up how to disable keyword searches. I just assumed "it looks for a prefix, if I add a space it won't trigger and the space won't affect my search". And it works! If that was unintended, it's a happy serendipity. Please don't force people to use a question mark, it's harder to type and it's impossible to guess.

you can always do as the FAQ says and press ctrl+k to select the omnibox and force a search instead of pressing ctrl+l

That doesn't work on Mac.

not sure if there's a keyboard shortcut on macOS ... don't know how to look them up.  use a diff laptop ? ;)

Able to reproduce this issue on reported version 60.0.3112.113 and on latest canary 63.0.3227.0 using Mac 10.12.6,Ubuntu 14.04 and Windows 10 with steps mentioned in comment#0.

This issue is seen from M57. Till then Secure shell is not compatible with Chrome. Hence considering this as Non-regression and marking as Untriaged for further investigation.

I'm not sure about pkasting@'s philosophy here.  Invoking a custom search engine by typing the name (as opposed to tab-to-search) is an intentional user action.  I think if the user typed a leading space, that's a pretty good signal something else is going on the users' mind.

Leading spaces have not invoked normal custom search engines for a long time, and we've never seen a complaint about that.  Thus, I think that's the right behavior.

I'd like to fix this by making leading spaces not invoke a omnibox extension as well.

> Till then Secure shell is not compatible with Chrome

err what ?  i don't know how you made that jump in logic, but that doesn't make any sense.

> I'd like to fix this by making leading spaces not invoke a omnibox extension as well.

agreed that extension keywords should behave the same as search engine keywords.  no opinion on leading space behavior.

The philosophy is based on assuming leading whitespace is unintentional/not meaningful.  That's consistent with e.g. stripping leading whitespace on paste.

Having a leading space mean something in any context (be it search keywords or extension keywords) seems unintuitive; why would I expect that to happen?  It's very hard to see that you typed a leading space, and it's easy to have one there by accident.  If we made a leading space force a search with the DSE (as a leading '?' does), that would at least be clear (but I wouldn't really like that behavior either).

So I agree that these should be consistent, but I still weakly think that they should consistently ignore a leading space.  I could be convinced otherwise.

I'm hesitant to mention it, lest someone go and file that as a defect, but pasting never triggers keywords (whether search or extension keywords). And that's entirely appropriate! It would be extremely annoying if it did.

So the model is NOT:
1. The user inserts text whichever way (typing, pasting, dragging, etc.), and pressed return.
2. Check if the inserted text starts with a keyword.

Instead, it is:

NORMAL MODE:
0. The field is empty.
1a. The user starts typing in the field. If the user starts by typing a keyword, go to KEYWORD MODE. If the user types anything else, go to 2.
1b. The user starts by pasting text in the field. Go to 2.
2. The user may type or paste more text. This is just appended. When the user presses return, go to 3.
3. Perform a normal search with the contents of the field, stripping whitespace.

KEYWORD MODE:
0. The field changes shape, adding a section for the special search mode. The field after the special indicator is empty.
1a. If the user types a backspace, the special indicator is removed. Go back to NORMAL MODE.
1b. If the user types anything else, it is appended to the query. All editing (including select all, cut, etc.) also applies to the text after the special search indicator.
2. When the user presses return, perform the keyword search with the contents of the field.

So, the only time when the field switches to keyword mode is when the special keyword is typed (not pasted!) when the field is empty. In any other state (as well as when it is pasted) it is typed as normal text. Similarly, the only time when the field switches back from keyword mode to normal mode is when the user types backspace when the field is empty.

This sounds complicated when written down, but it's actually quite easy to understand in practice, especially since the field changes shape to show what mode it is in.

The stripping of whitespace can (should) be applied on the query text when the search is performed, but by that point the search mode has already been established. Saying "well, but if we strip the whitespace it is as if we had never typed it, and in that case it would have been a keyword search" applies the wrong mental model.

More concisely, the model is not:
1. Type query, press return.
2. Based on the query text, decide if it's a normal search or a keyword search.

But instead it is:
1. Type query and optionally switch search mode using certain interactive operations.
2. Perform the query in the current mode.

> As an aside, if the person who implemented extension keywords had just reused the same code that handles search keywords, they would have gotten consistent behavior for free. It must have taken some considerable additional effort to get it wrong...

please don't editorialize.  if you don't have the background for the code or understand the reasons behind changes, just leave it at that.  throwing rocks doesn't really help anything.

Pasting not triggering keywords is intentional.  It would be surprising for pasting to do that.

As for describing the model for how this stuff works... I designed it and mpearson co-owns it, so hopefully we have some grasp on it.  The question of how to handle leading whitespace is one we've never fully specified, much as trailing whitespace sometimes behaves inconsistently.  A lot of the current behaviors are emergent from how the code was implemented, rather than intentionally designed.

Well, if the behavior is emergent I figured it may be interesting to know how a user models it.

But we can keep things even simpler:
- The search keyword behavior which "emerged" over time is well-established and has not received complaints (as mpearson pointed out). Users are used to it and are happy with it (whatever mental model of it they might have).
- The extension keyword behavior is inconsistent with the search keyword behavior in places, simply broken in other places, and has received complaints (at least this one).
- Everyone agrees that the two behaviors should be the same.

By simply making the extension keyword behavior identical to the existing search keyword behavior, you can solve the issue while avoiding the risk of creating new ones.

The root cause is the KeywordProvider doesn't check the allow_exact_keyword_match() status.  I had a tentative change to fix this,
https://chromium-review.googlesource.com/c/chromium/src/+/701418
that now I think is wrong...

As I fixed it, I noticed that omnibox extensions get sent the input even if they're not explicitly invoked.  For example, the input "cr foo" (if I have an extension "cr") and I am not in keyword mode (for example I typed "cr ", entered keyword mode, press backspace to leave it, then typed "foo"), the input "foo" is still sent to the "cr" extension.

That seems wrong.  I don't think extensions should see the input if the user isn't explicitly sending the input there.

Search provider, for custom search engines, take the opposite approach.  If the user has a custom search engine "cr" and again has "cr foo" in the omnibox without being in custom search / keyword mode, Chrome does not send the input "foo" to the custom search engine.  In fact, it goes even further -- it doesn't create the "Search cr for 'foo'" match anywhere in the dropdown.

I think both of these things should align.

I'm leaning toward them aligning on a middle ground.  In particular, if the user has a keyword (omnibox extension or custom search engine) in the query but hasn't explicitly invoked it, show a match in the dropdown for "Search keyword for text" but don't send "text" to the keyword to fetch additional suggestions.

pkasting@?

Actually, I'm not sure we do my suggestion for omnibox extensions.  The only way to get proper rendered text from an extension is to call the extension's OnInputChanged, which may yield multiple suggestions.  Perhaps we need to not offer any suggestions from the extension if the keyword is not explicitly invoked.

what does "explicitly invoked it" mean ?

Yeah, I think aligning the extension behavior with the custom keyword behavior (where if not explicitly invoked these are basically ignored) is probably safest.

Actually, turns out I was wrong: we can create a what-you-typed for an extension keyword without querying the extension.

This is ready for review; I'll send it out sometime.
https://chromium-review.googlesource.com/c/chromium/src/+/701418

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/31c2066fb04ade8b1474c27054f425fe8a72d04f

commit 31c2066fb04ade8b1474c27054f425fe8a72d04f
Author: Mark Pearson <mpearson@chromium.org>
Date: Mon Nov 27 17:20:25 2017

Omnibox - Extensions - Don't Allow Them To Be Default When It's Surprising

In particular, if allow_exact_keyword_match() is false (which basically
means not in keyword mode), make sure no suggestion from an extension
(i.e., has a keyword) is allowed to be the default match.

Also, make sure that if allow_exact_keyword_match() is false, don't
send the query the extension.  Seeing a ton of suggestion results
would be surprising.  Creating the what-you-typed match for the extension
is okay though, as Chrome does for partially-typed custom search engine
names when not in keyword mode.

Includes a test.

Bug:  769834 
Change-Id: I81ca093b655130c08ebe46645dcaa5468d701469
Reviewed-on: https://chromium-review.googlesource.com/701418
Commit-Queue: Mark Pearson <mpearson@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519322}
[modify] https://crrev.com/31c2066fb04ade8b1474c27054f425fe8a72d04f/chrome/browser/extensions/api/omnibox/omnibox_api_interactive_test.cc
[modify] https://crrev.com/31c2066fb04ade8b1474c27054f425fe8a72d04f/components/omnibox/browser/keyword_provider.cc