Manual regression range:
Good Build: 53.0.2756.0
Bad Build:  53.0.2757.0

Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/5f94fda863b8540f99eb571b4f94c8dd24dba406..47379284a4a83df80f1f539e87a069164c558d2e?pretty=fuller&n=10

Suspecting: r397505 

Deleted: Actual_Url.mov 866 KB

Actual_Url.mov 866 KB Download

Deleted: Expected_Url.mov 1.0 MB

Expected_Url.mov 1.0 MB Download

Adding RB label as this is a recent regression.

Broken by r397505: We blocked page initiated navigations to view-source urls. I didn't know that dragging & dropping URLs into the page cause a page-initiated navigation, I'd expect them to be browser initiated.

Charlie, any thoughts? Do you think this is a wontfix?

This shouldn't be WontFix.  I think ideally this should be considered browser-initiated.

That's what I was thinking, but I'm not sure if there is an argument against it.

creis@ : Could you please take a look into this as issue still persists on the latest canary 53.0.2773.0

How is this a P1 stable blocker?  It only affects dragging view-source URLs into the content area.  That seems very uncommon to me, so I'd suggest lowering the priority to P2 and removing the blocking label.

I'm not sure if it's possible to treat dragged URLs as browser-initiated navigations or not.  dcheng@, do you know how dragged navigations work?

I imagine the renderer is the one that decides to translate the drag into a navigation (much like link clicks and other renderer-initiated navigations).  It seems problematic to say that the renderer can't do navigations to view-source URLs while allowing it to do drag navigations to them.  Wouldn't that make the protection in r397505 meaningless, such that a compromised renderer could always just say it's a drag operation?

Clearly we can't let the renderer make that determination.

At the risk of speaking out of my ignorance, I think the way this should work is that the renderer should decide whether something in the page content is going to consume the drag contents (e.g. for when you're dragging an image onto Google Image Search).  If nothing does, the browser is free to do a browser-initiated navigation of the renderer to the desired URL.

It's possible to make this work. Basically, in https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/page/DragController.cpp?rcl=0&l=274, we'd want to have it call back out to the browser to navigate on its behalf. In theory, pretty simple...

(The browser will have to save a copy of the URL, so the call out to the embedder would just be an IPC telling it to take a navigation with the drag data it already has)

based on c#7, reducing the priority and removing blocker label.

Please add if required.

Moving this nonessential bug to the next milestone.

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

Note:Above issue is still reproducible on latest canary version i.e 55.0.2878.0 (Official Build)

 Issue 622589  has been merged into this issue.

Still reproduces (dragging a view-source: URL to the content area causes a navigation to about:blank).

meacer@, are you still planning to fix this?

Removing DataTransfer and Options components, adding Navigation component.

> meacer@, are you still planning to fix this?

It's low priority, so yes but not anytime soon. If anyone else is interested, please feel free to take it.