Avoiding Unexpected Navigation

For over twenty years, browsers broadly supported two features that were often convenient but sometimes accidentally invoked, leading to data loss.

The first feature was that hitting backspace would send the user back one page in their navigation history. (Dec 2022 Update: I’ve been using this feature for 25 years or so now and only today did I realize that if you hold backspace, you’ll keep going back.) This shortcut was convenient for those of us who keep our hands on the keyboard, but could lead to data loss– for instance, when filling out a web form, if focus accidentally left a text box, hitting backspace could result in navigating away from the form. Smart websites would warn you with an OnBeforeUnload handler, and some browsers tried to restore the contents of the form if the user understood what happened and hit “forward”, but these protections are imperfect and might not work for all forms.

One of the IE browser UI leads complained about this behavior annually for a decade, and users periodically howled as they lost work. Finally, circa 2016, this feature was removed from Chrome and Microsoft Edge followed in 2018. If you happened to love the old behavior and accept the risk of data loss, you can restore it via extension or in Edge 86, via the edge://flags/#edge-backspace-key-navigate-page-back flag.

The second feature was drop to navigate. Dragging and dropping a file into the browser’s content area (the body of the page) would, (unless the page’s JavaScript was designed to handle the drop, e.g. to upload it or process it locally), navigate to that local file in the current tab. Some folks like that behavior– e.g. web developers loading HTML files from their local filesystem, but it risks the same data loss problem. If a web page doesn’t accept file uploads via drag/drop, the contents of that page will be blown away by navigation. Back in 2015, a bug was filed against Chromium suggesting that the default behavior was too dangerous, and many examples were provided where the default behavior could be problematic. Yesterday, I landed a tiny change for Chromium 85 [later merged to v84] such that dropping a file or URL into the content area of a tab will instead open the file in a new tab:

Dropping in the content area now opens it in a new tab:

If you do want to replace the content of the tab with the dropped file, you can simply drag/drop the file to the tab strip.

A small white arrow shows you which tab’s content will be replaced:

Dropping the file between tabs on the tab strip will insert a new tab at the selected location:

Chrome (85.0.4163/v84) and Microsoft Edge (85.0.541) include this change; it was also later merged to v84. Microsoft Edge Legacy didn’t support drop to navigate. Firefox still has the old behavior; the closest bug I could find is this one. Safari 13.1.1 still has the old behavior and replaces the content of the current tab with the local file. Safari Tech Preview 13.2 Release 108 instead navigates the tab to an error page (NSPOSIXErrorDomain:1 Operation not permitted”).

-Eric

Published by ericlaw

Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ Microsoft 2001-2012, and 2018-, working on Office, IE, and Edge. Now a GPM for Microsoft Defender. My words are my own, I do not speak for any other entity.

Leave a comment