[Spike] Immediately hide the page when the Exit this Page button is interacted with

[querkmachine]

Spike for alphagov/govuk-design-system#2389. Immediately applies a white overlay on top of the current page when the Exit this Page button has been activated, to prevent a slow connection potentially leaving the page content visible for longer than desired.

Tested in:

• Apple Safari 16.0 (macOS)
• Apple Safari (iOS 12–16)
• Google Chrome 106 (macOS)
• Google Chrome (Android 9–13)
• Mozilla Firefox 106 (macOS)

Changes

• JavaScript now creates and injects a new HTML element before the closing body tag when the button has been activated.
  • The element is at the root of the document, rather than nested within the EtP component, to avoid potential issues with how z-index works within nested elements.

Investigations

Does the ghost page need some text or a loading indicator?

I personally don't think this is necessary, for the following reasons:

• Browsers do not usually show loading information within the viewport, rather this information is in the browser UI. It is therefore unusual to show loading text or graphics on the ghost page, and this may get noticed by tech-savvy abusers.
• In-page loading indicators, such as those used by SPAs (e.g. Gmail), are usually branded according to the service rather than being generic. A loading indicator would therefore be expected to match the appearance of the service the button is directing to, which we don't control.
• Even if we create a loading indicator that purposefully does not align with the GOV.UK design language, GOV.UK is well-known and used enough that—with time—the design of the ghost page may become recognisable.
• The user has, presumably, knowingly activated a function that hides the current page, thus they do not need an indication of what is happening.

With those aspects in mind, I believe—to quote Ronan Keating—"you say it best, when you say nothing at all".

Does the ghost page functionality still work if the button is a standard link and doesn't use e.preventDefault?

In all browsers tested, the ghost page is activated without requiring preventDefault.

What are the risks of the functionality breaking and leaving the user on a screen they cannot interact with?

If the component is misconfigured and the URL being redirected to is malformed, or it directs to a URL that cannot be displayed by the browser and will be downloaded instead (e.g. a Word document), then the user will be stuck on the ghost page.

In Chrome and Safari, clicking the back button from the redirected page restores the page's previous state—including the white overlay. (A fix for this problem exists on the conditional radio button reveals, so may be resolveable.)

If the user purposefully halts the loading of the new page, then they will remain on the ghost page. This is potentially a problem in conjunction with the 3× Escape key functionality, as all tested browsers will stop an in-progress page load when the Escape key is pressed. For example, if a user accidentally presses the Escape key four times, they will activate the ghost page but halt the loading of the subsequent page.

Other note: Scrolling on mobile devices

On both Safari/iOS and Chrome/Android, the user is still able to scroll the page when the 'ghost' overlay container is open. When doing so, page content can be briefly seen below the container.

This is because the overlay is styled with position: fixed with all sides (top/right/bottom/left) set to 0, however scrolling causes the mobile UI to expand and collapse, in turn changing the dimensions of the 'ghost'. I don't think this is a blocking issue, as it's only possible during the brief period between the ghost page kicking in and the user being navigated away, and it requires user intervention to make occur.

[owenatgov]

Solid work once again @querkmachine. Some thoughts:

• I wasn't able to test this due to an error on line 29 of the js. What's happening is that when you activate the button using esc, nothing is passed to the event handler and it's trying to read target of a null value. This isn't exactly an abstract idea though so it's not stopping me from interrogating your findings too much. Only joking it works great!
• I agree with everything you've said on if the blank page needs an indicator or not. Gold star for excellent use of a Ronan Keating quote
• The esc key problems have come up multiple times now and I think we have a mounting case that we should use something other than 3xEsc to trigger the button from a keyboard. A 4th esc key press stopping navigation is a problem regardless of the ghost page, just now it leaves the user on a blank page. Some sub-thoughts off of this one:
  • A possible solution would be to remove the ghost page on a 4th esc key press but that then leaves the user on the page they were already on and no navigation. We could possibly preventDefault on all proceeding esc key presses but that's now interfering with browser functionality and stopping folks who might legitimately want to stop navigation
  • The esc key is additionally a problem because it isn't considered a trigger for user activation. This has resulted in an odd leftover mystery where if you don't trigger user activation but activate the button on the keyboard (which isn't user activation itself) then navigation is triggered but it replaces instead of navigating normally, which could be disruptive especially for screen reader users as from testing, screen reader autoscroll on page load plus the esc key doesn't trigger user activation.
  • @davidc-gds Had the idea when I spoke to him about this about using a different combo instead of 3 esc presses eg esc then shift. From these findings and others, something that ended with anything other than esc would solve a lot of our problems.

[querkmachine]

I wasn't able to test this due to an error on line 29 of the js.

Fixed. Shh. 🤫

[querkmachine]

I've now tested this in a few versions of Safari on iOS and Chrome on Android. I've added a new section, "Other note: Scrolling on mobile devices" into the findings. The other sections remain accurate based on my experiences.

[christopherthomasdesign]

Sorry for the delay looking at this. I think it looks good, it works immediately and doesn't feel wrong. Agree that a plain white screen is preferable to trying to add any visual indicators. V nice enhancement 👍

[owenatgov]

I didn't get around to merging this so I'll give @querkmachine that honour. I have one errant comment but otherwise this looks great.

[owenatgov]

Lovely 💪🏻