How to prevent the page from going to "AllItems.aspx" after deleting a list item or a document in SharePoint 2013

Abouth a month ago on the 19th of November, I noticed something while I was cleaning up my site. I discovered that when I deleted a list item or a document from a list or library, the browser would send me to the "AllItems.aspx" of that list or library.

This was something I didn't really pay attention to at first, but then it came to my mind that end users might find this confusing since they would suddenly end up on a different page whenever they deleted something. Off course I understand that you probably wouldn't find this confusing at all, but imagine that a user with no knowledge of anything related to IT or computers would be in that situation. If such a user would end up on a page that no longer has the trusted design with a title and a paragraph of text, and a list or library that is suddenly showing way more columns than what he/she is used to see, that user would probably end up sending me an e-mail asking me for help because he/she is stuck. Yeah.

To avoid any confusion, no matter how small the problem, I wanted to make sure users would never end up on the "AllItems.aspx" page whenever they deleted something. So, not knowing where to start and not finding any relevant results on Google, I asked the question on Stack Exchange. I had thought that something like this wouldn't be so hard to figure out, but was dissappointed when my first and only "answer" was just a comment saying that I could take pointers. After a few weeks with still no solution, I gave up hope and started a bounty on the question.
Suddenly many more answers appeared, yet none were offering me an example in JavaScript. Most answers required me to use C# and seemed way to complicated for a problem this small, and after a while I thought that maybe my question wasn't clear enough.

Until someone answered with three options, one of which was to use cookies. When I started my search, I discovered that there was a successor to cookies. Named HTML5 Web Storage.

The logic behind the idea

First of all, we notice that when you want to delete something (be it a list item or a document, I'll just call it "item" from now on), you first need to click on the edit button for that item before you can choose to delete it. When I edit an item, it opens in a modal dialog. As you may or may not know, the URL of a modal dialog contains "EditForm.aspx".
If I then choose to delete the item, it directs me to the "AllItems.aspx" page. Based on this, we now know that we can write a piece of code that will only run when the user ends up on the "AllItems.aspx" page, having the "EditForm.aspx" page as its referrer.

Next, we just write a piece of code that will take us back to the previous page. But pay attention: technically, the previous page is the modal dialog. We need to go back to the page before we launched the modal dialog, so the page on which you clicked on a list item from a list or a document from a library.

To save the URL of that page somewhere, I used HTML5 Web Storage.
At this point, I just want to share the code with you. After all, there's really not much left to explain.

The actual code

var ref = document.referrer;  // Stores URL of previous page.
var url = window.location.pathname; // Stores URL of current page.

// The following code will run if the user edits a list item or properties of 
// a document.
if (url.indexOf("EditForm.aspx") > -1) {
 sessionStorage.setItem("page", ref);
}

if (url.indexOf("AllItems.aspx") > -1 
    && ref.indexOf("EditForm.aspx") > -1) {
 window.location = sessionStorage.getItem("page");
}

There you have it! It can't be easier, really!
If you follow the code, you'll see that if the URL in your browser window contains "EditForm.aspx", it will store the URL of the "previous" page as a session object. As soon as the URL in your browser window contains "AllItems.aspx" AND if the referrer (aka URL of the previous page) contains "EditForm.aspx", it will set the window location to the URL we stored as a session object earlier. The user won't even see that he/she has been redirected back to that page.

To make things work, you'll need to make sure that you've put a reference to your script in your master page. I had written the code in a new JavaScript file named "no-all-items.js" and added a reference to it in the master page:

<!--SPM:<SharePoint:ScriptLink language="javascript" ID="scriptLink10" 
 runat="server" OnDemand="false" Localizable="false" 
 name="~sitecollection/Style Library/Scripts/no-all-items.js" />-->

And there you have it. Make sure your script is checked in, as well as your master page, and you're ready to go!
Enjoy!