Unable to reproduce this issue on reported version 62.0.3202.94 and latest dev 64.0.3278.0 using Ubuntu 14.04 with steps mentioned below.

1. Navigated to https://en.wikipedia.org/wiki/Main_Page
2. Selected entire page using ctrl+a and dropped in omnibox and observed 413. That’s an error.

Your client issued a request that was too large. That’s all we know. page on dropping into omnibox.

@Reporter: Could you please check the video and let us know if we miss anything. And also please guide us with a screencast if possible. This would help us in further triaging of the issue.

Thanks!

It looks like you successfully reproduced the problem.  You received a 413 response from Google, but the text you dragged *was* was sent to the server.

If you really wish to not see a 413 response, just select less text; something in the range of 6KB of text is still enough to get Google to do a search.  Sample page: https://www.sublimetext.com/ - select all and drag into the address bar to see Google do a 4KB search.

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I know this doesn't address the root cause of the complaint, but if your default search engine is Google and you are signed in, you can go to Google's search history interface and delete the query from Google's logs.

We should decide if we want a limit on the amount of text that can be dragged and dropped and cause a search.

The size of text dropped doesn't correlate with the likelihood that the drop was accidental and contains private data you didn't want sent.  Therefore, adding a cap won't do anything to fix the core problem here; I think it would simply feel like an arbitrary behavior inconsistency (albeit one that happened very rarely).

I think the real fix, as noted at the end of comment 0, would be to remove auto-navigation on drop.  I think that's reasonable to consider.  I would expect drop to paste, not paste-and-go.  Users can already navigate-on-drop by dropping in the frame or tabstrip, so we're not losing a lot of functionality if we make this just paste.

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

commit 620133d59810d54853d1095e9fc98903d1b1790a
Author: sangwoo.ko <sangwoo108@gmail.com>
Date: Tue Jan 23 06:18:15 2018

Don't auto-navigate on drop into omnibox

When a string is dropped on the omnibox view, we shouldn't navigate automatically.
Just paste string on that.

Bug:  791259 
Change-Id: I804941f8d007392f9fc6c6ac3a497cf101f3c879
Reviewed-on: https://chromium-review.googlesource.com/873110
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531167}
[modify] https://crrev.com/620133d59810d54853d1095e9fc98903d1b1790a/chrome/browser/ui/views/omnibox/omnibox_view_views.cc
[modify] https://crrev.com/620133d59810d54853d1095e9fc98903d1b1790a/chrome/browser/ui/views/omnibox/omnibox_view_views.h
[modify] https://crrev.com/620133d59810d54853d1095e9fc98903d1b1790a/chrome/browser/ui/views/omnibox/omnibox_view_views_browsertest.cc

You've broken the historical feature supported in all browsers for 10+ years - navigating to an URL drag'n'dropped into omnibox e.g. from another tab.
It was very convenient to be able to drag URLs from other tabs/windows or from other browsers.

You can still navigate the current tab by dropping onto that tab in the tabstrip.

Yeah, I can, forgot about that.
However what about the broken interop with other browsers?

Also, previously I could drop the URL into a partially obscured tab that has only omnibar visible, but not the tab in the tabstrip.

Not all browsers supported dragging onto the address bar as a way of navigating immediately.  The other one I have on this machine (Edge) doesn't allow dropping a link onto its address bar at all.

You can also still navigate by dropping on the omnibox by simply hitting the enter key after dropping.  So while doing things that way takes one keypress longer, it also makes it easier to e.g. navigate to a variant of your drop (by editing before dropping).  And in my memory, at least one other browser I'd tested behaved this way.

Overall I'm not convinced this is the sort of thing where there's such existing consistency, and the new behavior is so much more difficult to use, that we need to revert.

#14 >Not all browsers supported dragging onto the address bar

Chrome, Firefox, IE combined are ~90% of the browsers used over the last 10 years or so.
And all of them navigated to a drag'n'dropped URL.
Edge is still a work-in-progress so it misses useful features and API.

---------------------------------------------------
#14 >by simply hitting the enter key after dropping

Having to press something on keyboard for a mouse-only operation is an obviously bad UX.

---------------------------------------------------
#14 >it also makes it easier to e.g. navigate to a variant of your drop (by editing before dropping

Yes, but it's rarely needed. Are there any metrics on how often a manually pasted URL is modified before navigating vs (pasting&navigating + dropping&navigating)?

---------------------------------------------------
#14 >Overall I'm not convinced this is the sort of thing where there's such existing consistency, and the new behavior is so much more difficult to use, that we need to revert.

This can't really be a rationale to break the historical behavior that existed for 10+ years in the major browsers.

...continued:

#14 >it also makes it easier to e.g. navigate to a variant of your drop (by editing before dropping

What about drag'n'dropping a local file into omnibox? The new behavior doesn't make *any* sense because why would a user need to alter the local file's URL before displaying it? Obviously this won't be needed in 99.9999% of use cases.

pkasting@: why can't we have URLs auto-navigate and non-URLs just paste?  That seems like it would satisfy the original complaint here (which is why we switched to pasting from navigating) and the new complaint about the fix.

@17: Navigating or not based on how we parse the underlying type seems extremely surprising to me.  The current behavior is predictable, which feels like a bigger win.

While the original complaint here is one reason I proposed switching away from auto-navigation, it's also extremely unusual to drop text in a text box and have it effectively "submit the form"/take action immediately.  And the drop cursor does not indicate navigation either.  IOW, I proposed changing the behavior because the old behavior didn't make a ton of sense, and the change fixed the complaint here as a side benefit.

@15: You are correct that "edit before submitting" is probably rare, but then again, so is "I can't drop on the tabstrip but I can drop on the omnibox because the former is obscured but the latter isn't".  So either we're talking about edge cases as important or we're not :).

There are also still mouse-only ways to navigate even when the tabstrip is obscured, e.g. right-click -> paste-and-go on the omnibox.  As long as we still have an easy drag-and-drop target in the common case, these other alternates seem sufficient to cover the alternate cases.

As for other browsers doing something for years, while that isn't to be thrown aside lightly, we intend for Chrome to exist for more than 10 years into the future, and so the main question we should ask is: if we were designing this anew today, what would be the most plausible behavior?  For the reasons given above, I think the answer would be to not navigate on dropping, so I think that should be the biggest consideration in what we do going forward.

My point is that the new behavior is not better for URLs so it doesn't make sense to break the old one.

What about the lack of practical meaning in preventing auto-navigation of a local file drag'n'drop into the omnibox? It can't really be the intended behavior as it's not useful. Obviously, the new behavior is worse at least in this particular use case, which is not rare so it can't be dismissed as an edge case.

As for using "Paste and go", it won't help because the drag'n'dropped URL is not in the clipboard. Since Chrome doesn't show any "Go" button in the omnibox there's no way to avoid using keyboard except for not using drag'n'drop altogether.

@19: Local file URLs are not meaningfully different than other URLs in terms of making more or less sense to navigate or not on drop.  And yes, dragging and dropping a local file into the omnibox is incredibly rare, even more so when the tabstrip isn't accessible as an alternative.

As for URLs not being in the clipboard: yes, you'd have to put them in the clipboard first.  That's generally possible without the keyboard.  Is it as convenient?  No, but again, this is a fallback for the case when you can't drop on the tab and you can't access the keyboard.  If either of those two are in play, do that instead.

Supporting keyboard-free, clipboardless navigation via drop to windows whose tabs are inaccessible is not a case that I consider important enough to revert this change for.

Let's define what we compare against when we mention "rare". 
I'm afraid you're talking absolute numbers, while I compare within the same group of activities affected by r531167: drag'n'dropping a URL/file.

AFAIK, what's extremely rare is the need to edit an URL after drag'n'dropping it compared to auto-navigation.
The new behavior implies it's the other way around (otherwise it's uncalled for).

I see no benefits here for drag'n'dropping URLs/files, only the mentioned drawback.
Do you simply dismiss the entire use case of drag'n'dropping a URL/file as negligible?

I feel like I'm repeating myself, so I'll probably not reply here further unless I have something new to say.

The activity here is "dragging any text at all into the omnibox", not just dragging URLs.

The reason for the new behavior is not to allow editing before navigation (since while it does allow that, that case is not very important, and I regret mentioning it above since it's clearly been so distracting), it's to make the drop behavior more coherent with dropping text onto other textfields elsewhere, more consistent with what the existing drop cursor suggests, and fix the original complaint on this bug.

The change here isn't designed to benefit trying to navigate by dropping a URL, but my argument is that for most cases it doesn't significantly harm it either, because the tab is available as a drop target.  It is rare that the user can't drop on the tab, and when they can't, there are other ways to do this.

#22 >The activity here is "dragging any text at all into the omnibox", not just dragging URLs.
#18 >The current behavior is predictable, which feels like a bigger win.

I'll reiterate just in case I didn't highlight the difference: when a local file is drag'n'dropped into the omnibox, it wasn't text, but a file (at least from a user's point of view), so the new behavior doesn't look predictable to me. Rather, confusing. Another use case is dragging of the source URL via the (i) icon or "Secure" prefix inside one tab's omnibox and dropping it into another tab's omnibox (because it's bigger than the tab handle in the tabstrip) - in this case it's not the text that's being dragged (at least visually).

It is a fair distinction that when the source of the drag doesn't appear to be text, but a non-textual object, dropping text is less clear than in the case where the drag source is text.

I'm not sure we're able to distinguish those cases, though, at least when the drag source is not inside Chrome.

>not sure we're able to distinguish those cases, though, at least when the drag source is not inside Chrome.

Chromium already knows that by using DragQueryFile WINAPI.