Omnibox should accept and navigate URLs dropped using drag and drop.

Omnibox should accept and navigate URLs dropped using drag and drop.

BUG=157690
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=171125

[sky, 2012-12-03 23:46:40]

https://codereview.chromium.org/11416327/diff/1006/chrome/browser/ui/views/om...
File chrome/browser/ui/views/omnibox/omnibox_view_views.cc (right):

https://codereview.chromium.org/11416327/diff/1006/chrome/browser/ui/views/om...
chrome/browser/ui/views/omnibox/omnibox_view_views.cc:789: if (data.HasURL()) {
Shouldn't this match the windows implementation? Can we refactor the two to
share?

[varunjain, 2012-12-04 18:44:13]

https://codereview.chromium.org/11416327/diff/1006/chrome/browser/ui/views/om...
File chrome/browser/ui/views/omnibox/omnibox_view_views.cc (right):

https://codereview.chromium.org/11416327/diff/1006/chrome/browser/ui/views/om...
chrome/browser/ui/views/omnibox/omnibox_view_views.cc:789: if (data.HasURL()) {
On 2012/12/03 23:46:40, sky wrote:
> Shouldn't this match the windows implementation? Can we refactor the two to
> share?

the windows implementation handles all drops in OmniboxViewWin, whereas, here,
we only handle URL drops while simple text drops are handled (rightfuly so) in
NativeTextfieldViews. There are about 5 lines of code that are common between
OmniboxViewViews and OmniboeViewWin that I can refactor to OmniboxView. IMHO it
is not worth doing that also because gtk has its own handling on drop and does
not look like can be merged (it does not even use OSExchangeData). It seems more
consistent to do this separately for Views and Win as well.

[sky, 2012-12-04 22:38:59]

LGTM

[commit-bot: I haz the power, 2012-12-04 22:54:11]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/varunjain@chromium.org/11416327/5001

[commit-bot: I haz the power, 2012-12-05 02:21:15]

Change committed as 171125