Confirmed in latest Canary.

The mouse equivalent of this is  bug 731252 .

Speculatively assigning to spqchan based on ownership of the related bug (#3).

Ooh - thanks for filing this!

This is not related to  Issue 731252  . E.g. this selection mode works in other toolkit-views textfields on Mac (e.g. Add bookmark).

OmniboxViewViews::ExecuteTextEditCommand() intercepts ui::TextEditCommand::MOVE_DOWN and makes it do model()->OnUpOrDownKeyPressed(1); That's OK.

What's not OK is that OmniboxViewViews::HandleKeyEvent() incorrectly assumes that all ui::VKEY_DOWN are TextEditCommand::MOVE_DOWN when in fact they could also be TextEditCommand::MOVE_DOWN_AND_MODIFY_SELECTION, which shouldn't trigger this behavior (at least on Mac).


In fact... a user can remap a down arrow to whatever text editing command they like via ~/Library/KeyBindings/DefaultKeyBinding.dict but a good fix for this is probably just to check for `shift` on Mac inside the ui::VKEY_DOWN case for OmniboxViewViews::HandleKeyEvent()

Over to elly to find an owner.

Similar to Problem 1, the Shift-Up keystroke no longer works in Chrome 69's Omnibox as it did in Chrome 68 and prior.

Chrome 68 and prior: Shift-Up in the Omnibox selects text from the cursor to the beginning.

Chrome 69: Shift-Up does nothing except for some confusing interactions with the suggestions menu.

Jeff Tulley noticed that in Chrome 69, Shift-Command-{Up,Down} behave as Shift-{Up,Down} did in Chrome 68 and prior.

 Issue 881369  has been merged into this issue.

 Issue 882210  has been merged into this issue.

 Issue 883729  has been merged into this issue.

pkasting: Is there any reason why shift-up and shift-down shouldn't select text before/after the cursor position on other platforms? Seems to me that this would be useful everywhere and it seems to be the default behavior in Windows text fields.

What Windows text fields did you try?  While this works in Edge, it doesn't work in File Explorer, Notepad, IE, or Firefox.

I'd be inclined to fix this on Mac and leave as-is on Windows; shift-home/end are the canonical ways to do this there.  I could be convinced otherwise (in part because Edge supports this).

> What Windows text fields did you try?

I tried a few different text fields in dialogs in the control panel and Outlook. It also works throughout Chrome (text fields in Blink and the search field at the top of various Web UI pages (chrome://settings, chrome://bookmarks, etc.)).

To me, this looks useful, not disruptive (shift-up/down currently doesn't do anything distinct from unmodified up/down), and simple to implement.

Is there an easy way to check how it was behaving on Chrome 68 on Windows and see if we should consider this being a regression?

It wouldn't be a regression on Windows since we've never supported this there.  It's a regression on Mac.

pkasting: Thanks, that makes sense

pkasting: Have I convinced you that this is worth adding to Windows? Or should I attempt more convincing? :)

FWIW, "adding" this to all desktop platforms is really just removing the Mac ifdef in https://crrev.com/c/1228576.

If you think it makes sense to add, I think you should go for it.

That's partly because you own this and it's your call, so you should do what you want even if I strongly disagree :).  But it's also because I'm not strongly opposed to this.  I'd omit it mostly out of principle because it feels like a Linux/Macism and not a Windows native behavior, and I try to avoid bringing other platforms' behaviors to Windows, but I don't think that's a strong reason.  And if this works in at least some places in Windows, maybe it's a UWP-ism, or some other "modern" Windows behavior, in which case we should support it.

jdonnelly: I can remove the ifdef in my branch, but I won't be able to test on Windows. Should we make this a separate bug or can someone test my branch on Windows to confirm?

maxmathieu: Go ahead and land what you've got. I just filed https://crbug.com/892216 to bring the behavior to the other platforms.

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

commit aa268735dc3916c9cf119bddc572e7e64cdb482c
Author: Max Mathieu <maxmathieu@google.com>
Date: Thu Oct 04 18:01:20 2018

Fix regression with Shift+Up/Down in Omnibox on OSX

When in Omnibox, Shift+Up/Down should behave like other input fields.

Bug:  863543 

Change-Id: I477752ebf08b3ae0065e141cc63c4c0c87f6f181
Reviewed-on: https://chromium-review.googlesource.com/c/1228576
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Max Mathieu <maxmathieu@google.com>
Cr-Commit-Position: refs/heads/master@{#596753}
[modify] https://crrev.com/aa268735dc3916c9cf119bddc572e7e64cdb482c/chrome/browser/ui/views/omnibox/omnibox_view_views.cc
[modify] https://crrev.com/aa268735dc3916c9cf119bddc572e7e64cdb482c/chrome/browser/ui/views/omnibox/omnibox_view_views_unittest.cc