Browsers generally do not do anything to tell the user when a drop is going to result in a navigation vs. a HTML5 drag/drop event. (That's likely because the browser doesn't have any real way to know before the drop occurs.)

In both Chrome and Firefox on Windows at least, this problem doesn't repro on Twitter, instead you get a pretty dotted outline around the place where you're supposed to perform the drop (see attached picture) and if you drop outside of that region, nothing happens. However, this isn't anything magic the browser is doing-- instead, it's thanks to custom script that Twitter includes. 

A simpler test page is https://html5demos.com/dnd-upload/, which shows in all browsers that if you drop outside the box, the browser treats it as a request to navigate to the local file:// URL, while dropping inside the box is treated as a HTML5 file transfer request.

This all suggests that a workaround for systems like Jira would be to include logic like that on Twitter. However, it's probably very practical to expect all websites to take on such custom code.

Deleted: TwitterDragDrop.png 41.8 KB

	TwitterDragDrop.png 41.8 KB View Download

Re #1: replace "probably very practical to expect" with "probably NOT very practical to expect"

"This feels reminiscent of the backspace issue that was recently fixed. Rarely it was used as intended, but mostly it was easy to lose your form data inadvertantly."

+1. Drives me nuts. The behavior probably dates from the days when image viewing applications were a thing you needed to install and browsers alleviated some of that pain.

That said... duplicate. Feel free to complain over there too. I'll add my complaint.