A deeper dive in the “Exit this page” button

Trauma-Informed Design Reflections #16

kon syrokostas
the Trauma-Informed Design blog
4 min readJun 11, 2024

--

Black logo text on light pink background saying “TID Reflection 16, 03–09 June”

In one of my earliest blog-posts I wrote about the “Exit this page” button, a component often used in websites that are built for/with survivors. Last week I was talking with the wonderful Tiziana d’Agostino and we realized that the implementation of that button is a bit more nuanced than it seems.

The idea behind the “Exit this page” button is that when someone browses a potentially unsafe website (e.g. a victim of domestic abuse searching for ways to escape) they need a way to safely exit it. In that case “safely” means that it’s hard (or ideally impossible) to get back to the unsafe website. The main way to do that is to make sure that the browser’s back button won’t work.

Unfortunately, this isn’t always possible.

To understand why, let’s look at how browser navigation works. As we navigate the Internet our browser keeps a list (more accurately a stack) of the websites we visited. This list is unique for each tab and is cleared every time we close a tab. It looks something like that:
page 0 → page 1 → page 2 → page 3 (current page)

When we navigate to a new page the browser will add this to the list and we’ll end up with something like that:
page 0 → page 1 → page 2 → page 3 → page 4 (current page)

Once we click the back button the browser will move to the page before the current one, so in the above example:
page 0 → page 1 → page 2 → page 3 (current page) → page 4

Because the last visited page remains in the list, we are able to use the forward button to get back to it. But if we then move to another page instead the list changes to something like that:
page 0 → page 1 → page 2 → page 3 → page 5 (current page)

Now let’s look at what happens in the case of the “Exit this page” button.

In most websites the “Exit this page” button is implemented using the following command: location.replace(targetUrl);
This replaces the current page with the one specified in the targetUrl. Because the page is replaced it no longer exists in the browser’s navigation list.

So for example if we are in this state:
page 0/UNSAFE (current page)

Pressing the “Exit this page” button would result to:
page 1/SAFE (current page)

As you can see page 0 has completely disappeared from the list which is why the browser can no longer get back to it when the back button is pressed. In the above case, since the list only has one entry, the back button will be disabled.

The situation is a bit trickier however when the list contains more than one page. For example:
page 0 → page 1 → page 2 → page 3/UNSAFE (current page)
would change to:
page 0 → page 1 → page 2 → page 4/SAFE (current page)

In that case, the back button will be clickable, but instead of navigating us to the previous page (the unsafe one) it will navigate us two pages back (to page 2). Things are fine until now and the “Exit this page” button fulfills its purpose.

But here is a situation in which this isn’t the case:
page 0 → page 1 → page 2/UNSAFE → page 3/UNSAFE (current page)
after the “Exit this page” button is pressed we would have:
page 0 → page 1 → page 2/UNSAFE → page 4/SAFE (current page)

In that case both page 2 and page 3 are unsafe, potentially because they are different pages of the same website (e.g. unsafesite.com/home and unsafesite.com/resources). The “Exit this page” button would protect us from visiting page 3 when navigating back, but pressing the browser’s back button would still get us to page 2 which is no better.

Unfortunately, and regardless of what ChatGPT will tell you, solving this problem isn’t trivial. There is no way to directly manipulate the browser’s navigation list and no way to keep some code executing after the navigation has happened. The only way I have found is to use web frameworks that override the default navigation behavior. This however isn’t possible when a website is built using low-code or no-code tools such as WordPress or WebFlow.

The big issue here is that the “Exit this page” button can give a false sense of safety to the person using a website by letting them believe that going back after it’s pressed is impossible. In general, it’s hard to communicate exactly which cases are covered by the “Exit this page” button, and this case adds even more nuance to that.

Personally, I’ve come to believe that it might be better to reconsider how the “Exit this page” button works. Since the button doesn’t clear the browser’s history anyways, it might be better to simply open a new tab and close the current one. This will at least clear the navigation list and “disable” the back button. Here’s the code to do that:

var win = window.open("https://example.com", '_blank');
win.focus();
window.close();

All these aren’t to say that the “Exit this page” button isn’t a useful component. I actually still see a lot of value in it. But it is to say that there are limitations in what it can do and that if those limitations aren’t handled gracefully they could cause harm.

--

--

kon syrokostas
the Trauma-Informed Design blog

Software engineer & trauma recovery coach. Exploring trauma-informed design.