Manual Bisect info :
Good Build : 53.0.2768.0
Bad Build : 53.0.2769.2

Narrow Bisect info:
https://chromium.googlesource.com/chromium/src/+log/edbac87b7a0fbe93a323840e2f143686e4065b10..d3a998e1c84c2162c79852454ab8944177fccaa7?pretty=fuller&n=10000

Suspecting : r399989 ? from Narrow Bisect.

@hush : Could you please help to reassign if your change is not the cause for this change.

Note : Above issue is also seen on Linux(14.04 LTS) and Mac(10.10.5, 10.11.4) OS.

Deleted: Actual_signin_overlay.mp4 1.2 MB

	Actual_signin_overlay.mp4 1.2 MB View Download

Deleted: Expected_signin.mp4 693 KB

	Expected_signin.mp4 693 KB View Download

Adding RB label as this is a recent regression

hush@, if your change indeed made this possible, is there some setup the sign in flow can perform on its web view to prevent accepting dragged links like this? If so, I'll be happy to implement it.

I'll take a look

re #3: I'm not very familiar with the <webview> tag. (CC-ed lfg@)

This issue is indeed caused by my change. When the URL is dropped, it changes from chrome://settings/ to "about:blank" because of the FilterDropData logic I added. 
https://cs.chromium.org/chromium/src/content/browser/browser_plugin/browser_plugin_guest.cc?rcl=0&l=808
chrome://settings/ is considered "unsafe" and converted to about:blank as a result.

I guess, the solution is just not to filter the data? --- dcheng@, what do you think?

By the way, if you drag and drop an innocuous URL like google.com, then things still work.

I think the ability for this to previously navigate to chrome:// URLs should be considered a bug.

We should fix it, but this is not the right level. See issue 619519 for more details.

So... is this working as intended?

The end result isn't very good... but yeah, I'd say so. There's a fairly straightforward path to fixing this for the non-<webview> case, but I'm not so sure how we'd fix it for legacy <webview>: the data roundtrips through the renderer, and at that point, we really can't trust what we got.

I'm confused about the difference between having the drag try to navigate to chrome://settings / about:blank (in Actual_signin_overlay.mp4) and having it put the text in the form input (in Expected_signin.mp4).

Trying to navigate to chrome:// URLs inside that webview is definitely a bug and a possible security issue (which should be caught in several places, like the FilterURL call you added).

I don't see a problem with allowing the text to be dragged into the form input as in Expected_signin.mp4.  Why did that change from being form input to being a navigation?

FWIW, I don't think we should allow any drags to be navigations inside the signin overlay, even if they're normal web URLs.  Is that feasible?

I agree that the best behavior would be allowing URL to be dragged as texts but not allowing navigating to the URL.
On top of my head, I don't know where/how do we decide to navigate to a dragged URL or simply insert the URL as input.

okay. After I read crbug.com/619519, I think the decision to navigate or to drop the URL as text is made in blink, and we want to change the decision maker to browser.
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/page/DragController.cpp?rcl=0&l=274

So I don't think there is anything to do here.
Merge into crbug.com/619519 ?

Moving this nonessential bug to the next milestone.

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

Just to update,

Able to reproduce the issue on Mac OS using canary build 55.0.2878.0 Thank you!