The  issue 633557  says it's by design and the web site should be smarter - a good one would declare an onbeforeunload handler to prevent data loss. That said, Chrome could be smarter itself and display the confirmation in case the user typed something in the current page.

Thanks for the reference in #1!

ellyjones@, since you provided some context in  bug 633557 , would you know whether having a confirmation before Chrome navigates away after drag&drop could be considered? Or which team should this be mentioned to?

Thanks for filing the issue!

@Reporter: As it would be out of scope for ET team to create an advertisement in any web page, It would be highly helpful if provided with sample test file which helps us to triage the issue in a better way. 

Hi vamshi.kommuri@,

There is no use in building a copy of https://www.ebay-kleinanzeigen.de, the reported issue is simple:

Currently, if one drags an image file over a Chrome tab and drops it, Chrome immediately navigates away from the current page and opens that image instead. That loses much of the state the page had (see the concrete case in #0).

This could be fixed in a number of ways, including adding a confirmation ("Do you really want to leave this page?").

vabr@: we could add such a confirmation - it would probably be the decision of the desktop UX folks.

+cc pkasting@

pkasting@: what do you think of adding a confirmation when navigating via drag & drop of an image? it's a little weird but it kind of makes sense.

Not a fan.  There are a lot of ways to navigate away from the current page accidentally and suddenly (e.g. clicking the mouse back/forward buttons), inconsistently solving one is unexpected; confirmation UI is suboptimal in general (much better to make actions undoable than to add confirmation); and on an intentional drag there's no particular reason why I'd expect this specific action to have a confirmation dialog.

I'd look to see why we have dataloss on nav away and if we can make our form restoration logic more intelligent to prevent it.

I agree it's really weird to focus on image dragging alone. I think a better idea is to confirm any navigation in the most affected case: when the user typed or changed something in the input/textarea element on the currently displayed page. Of course it might miss some custom element but that's rare.

That's a better idea, but it still has both false negative and false positive problems, and confirmation UI is still really annoying and fairly ineffective.  I still think a better route is to find out what specific aspect of this page is preventing us from restoring the entered data on return, and fix that.

Thanks all for ideas. And especially, thanks pkasting@ for the perspective showing the downsides of the confirmation.

I agree that special-casing the drag&drop would be just confusing patching up, and leave other problematic routes open.

I like the idea to restore more state (e.g., textareas don't seem to be restored) as a general improvement.

For drag&drop, I wonder if there is something to be improved in letting the user know whether the page is handling the drag&drop or whether Chrome is. In the case of https://www.ebay-kleinanzeigen.de/, the page has unfortunate graphics which confused me, at least, into believing that they are handling drag&drop.

As for using confirmation for every navigation suspected of being accidental -- the crux is determining "suspected" reliably. And I don't think Chrome can afford false positives (judging an intentional navigation as accidental), because that would just be highly upsetting for usage. In particular, it is often the case that the page seems to navigate with stuff filled into the form, without the form being submitted (a big challenge for our work on password manager), so triggering on that would be a no-go.