Essentially, the omnibox shows the target URL at the point of the drop but still allows updates to the markup underneath the now incorrect omnibox. The page navigation indicator (spinning circle) shows as the navigation slowly times out.

This looks just like  Issue 660498 

creis@ has thought the most about when it is and isn't safe to show the new URL on an uncommitted navigation.

creis@ -- Please take a look at this bug and share your thoughts. Feel free to assign it back to me if you don't know who should own this. Thanks.

The prior version of this bug was triaged at Medium and while I think a case could be made for low (due to the user interaction requirement), I'll mark this the same.

Comment 1: Yes, this sounds like  issue 660498 , or more specifically, the original report there (as opposed to comment 5 on that bug, which was a real issue and one we ended up fixing).

Here's my comment 4 from that bug, which applies here:

----
I don't think there's likely to be anything we can do here.

Drag n drop is basically no different than having the page tell the user to "copy this link and paste it in the address bar."  When the user initiates any navigation in the address bar, we intentionally show that URL until it commits or fails, even if the navigation is slow.  It's true that the currently visible page can change its appearance during this time, but it doesn't have much control over where the user is trying to navigate.

Mitigating factors: the spinner is still going, and Chrome doesn't show the lock icon for HTTPS URLs until the pending URL commits.

Note that pages themselves can't initiate this attack on their own-- when they start a navigation, we don't show the pending URL until it commits.

Also note that navigations might not commit (e.g., they might turn out to be a download or 204 response, leaving you on the current page), so we can't clear the current page during a slow navigation.

Nasko or Peter, do you have any thoughts on improving what Chrome does here?  If not, I think this can be marked WontFix.
----

I'm marking this as Low because the Medium rating for  issue 660498  was due to the no-user-interaction-required version of the attack from comment 5 of that bug.

Nasko/Peter/Eric: Any thoughts on changes we should make here, or should we mark it WontFix?

I don't think drag is much different than the copy/paste as creis@ pointed out. 

If we have any way of knowing that the drag start occurred in the content area, then it might be conceivable that we can treat the navigation as renderer-initiated, which will not put the URL in the omnibox until commit time. 

If the above isn't possible, I personally don't think there is much we can do.

It should be pretty easy to figure out if it's renderer initiated as long as an OSExchangeData is plumbed through, since it has a method called OSExchangeData::DidOriginateFromRenderer()  which can be used to determine this.

(I did a quick codesearch, and it looks like OmniboxViewViews::OnDrop() has an OSExchangeData: I'm not sure where tabstrip drops, etc are handled though)

"Renderer-initiated" is supposed to mean "the user did not explicitly do this and may be surprised that it's happening".  It would be inappropriate to set that on a drag-from-the-content area.

So I think we should not implement the suggestion in comment 10 even if we can.  That behavior feels fundamentally worse from an interaction perspective, and it would have ramifications like changing how downloads are filtering.

I vote for WontFix with no action.

I tend to agree with Peter here.  The drag shows you what URL you're dropping into the omnibox, so it's not surprising that it would show up there while you're navigating to it.  The spinner is still going and there's no lock icon, so I'm ok with not making a change here.

Thanks for the report, though!

If we ever did want to address this, couldn't we do something simple like an immediate navigation to about:blank before initiating the (potentially slow) navigation to the dropped URL? That would presumably block the exploit and it feels like it would be entirely reasonable from a user-experience perspective.

Comment 14: No, since not all navigations end up replacing the page.  It could be a download URL, for example.  This would add a disruption to the user experience that wasn't there before.

It's true that not all navigations replace the page (downloads, HTTP/204, HTTP/205, etc), but from a user-experience point-of-view, I expect anything that I drag/drop to the omnibox to result in a visible change, and blanking the page as the navigation begins seems not only reasonable, but desirable. 

Having said that, if we don't want to change this, I don't feel a great deal of passion about it.

kenrb@ has mentioned that the painting team goes far out of their way to minimize any blanking of the page between navigations, so I think we probably shouldn't go down that path.

The same logic could apply to typed URLs (where it's admittedly a bit weird that the URL you just typed disappears if it becomes a download or 204), but I think it would be a bad experience to blank the page when starting navigations that are dragged or typed.  Among other things, it means you can't click stop and stay where you were if the navigation is slow, and it makes the page load feel slower even when it succeeds.  I think it's just one of those places that browsers are stuck in a hard place because the address bar serves two competing roles (showing both where you are and where you're going).

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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

 Issue 763825  has been merged into this issue.

Adding estark and emilyschechter, since we've been discussing possible UI treatments to more clearly differentiate pending and committed URLs in  issue 719856 .  That would help with these reports as well.

 Issue 863287  has been merged into this issue.