Back button/history broken in Safari on reference pages

[antiboredom]

Most appropriate sections of the p5.js website?

Reference

What is your operating system?

Mac OS

Web browser and version

Firefox 137.0.2

Actual Behavior

The back button doesn't work in Firefox when browsing reference pages. Something about individual reference pages is filling the browser history. Note: it seems to work fine in chrome!

Expected Behavior

Going back a page from a a function reference should take you back to the main reference page.

Steps to reproduce

To reproduce, open the reference page, click on arc() (or any other function), scroll down, then try to go back a page (or just take a look at the history). This only happens if you scroll down a bit, so perhaps it has something to do with the embedded sketches?

Would you like to work on the issue?

Unfortunately I don't have time at the moment, but would be happy to take a look after may 15th if no one else is able to get to it before then.

[antiboredom]

Update: actually I think this is broken in Chrome as well...

[andysmith26]

confirmed in Linux Mint with FF 138.0.1

[andysmith26]

The scrolling threshold, below which the back-button is broken, seems to be the moment the content loaded in the astro-island tag appears on the page.

This is the console log when pressing the back-button.

Source map error: Error: URL constructor: is not a valid URL. Stack in the worker:resolveSourceMapURL@resource://devtools/client/shared/source-map-loader/utils/fetchSourceMap.js:56:22 getOriginalURLs@resource://devtools/client/shared/source-map-loader/source-map.js:73:24 workerHandler/</<@resource://devtools/client/shared/worker-utils.js:115:52 workerHandler/<@resource://devtools/client/shared/worker-utils.js:113:13

Resource URL: about:srcdoc Source Map URL:

Maybe related to https://github.com/withastro/astro/issues/11919 ?

[ksen0]

Thanks for the investigation, both! @antiboredom if you have time after 15th and if no one else volunteers, please ping here, happy to assign.

[limzykenneth]

I did a git bisect as I know this wasn't the behavior before, I tracked it down to be introduced by #812. I need to look up what preact is doing in this case but it seems to be pushing history entry whenever a sketch is unloaded on the page.

[limzykenneth]

Ok I think I found the root cause although it is not definitive. Every navigation within an iframe will be counted as a history entry in the top most document, typically changing the src attribute counts as a navigation as well which leads to a behavior in React/Preact where dynamic src attribute will cause iframe to navigate and add entries to the history API.

However we are not using the src attribute rather the srcdoc attribute that directly sets the HTML content of the iframe. In the current version when we unload the content of the iframe, we are setting srcdoc to undefined, that is interpreted by preact as a navigation because in practice it removes the srcdoc attribute entirely, and in my guess/understanding, is understood as a change in src and thus a navigation. What we can do instead is to set srcdoc to "" (blank string) instead which will preserve the srcdoc attribute while still unloading the content of the iframe, from my test, this is not counted as a navigation and does not add an entry to the history API.

@davepagurek Seeing as you did the original implementation, can you have a look at the above to see if it made sense to you. I'll make a PR to fix as such.

[wagedu]

Issue still present on Safari

[davepagurek]

Looks like this doesn't happen for me on Safari 18.2, but does for @wagedu in 18.4.

[andysmith26]

I'm on Safari 18.5 and seeing the same behavior as @wagedu.

Version 18.5 (20621.2.5.11.8)

[limzykenneth]

I'm not able to replicate this for Safari 18.5 on macOS 15.5. @wagedu @andysmith26 Can you please try again and see if it is working, maybe your browser had the cached version previously that didn't include the fix. Do try another browser if you can to see if it is browser specific if you are still seeing issues with Safari.

[wagedu]

I'm on Safari 18.4 MacOS 15.4 but @andysmith26 is on 18.5 It's browser-specific, and I reloaded without cache.

[ksen0]

Since I am not able to reproduce this (Chrome or Safari, MacOS), I'll tag this with "Help Wanted" - anyone who has ideas on tackling this is very welcome.

[msawired]

I can confirm it is a behavior that showed up in recent versions of Safari. Note that It is not specific to reference pages; it also shows up on the editor itself, as well as on OpenProcessing. In OP, I use a different method to post a form to the same iframe, yet still it counts as a history.

One solution I found, as a hack, to submit the form after an error. In such case, Safari doesn't register it as a new history event (go figure 🤷‍♂️). But then I disabled it because at some point it created pop ups on every submission when I pushed this update to production. I am working on figuring out the pop up issue. I will post my updates here.

let isSafari = navigator.userAgent.indexOf('Safari') > -1 && navigator.userAgent.indexOf('Chrome') == -1;
		if (isSafari) {
			console.groupCollapsed('Safari History Bug Workaround');
			//to prevent Safari history bug, make a fake fetch request and submit sketch form on catch
			fetch('about:blank')
				.catch(() => {
					$('#sketchForm').trigger('submit');
					console.groupEnd('Safari History Bug Workaround');
				});
		} else {
			$('#sketchForm').trigger('submit');
		}

I know that p5js editor doesn't use form method. But maybe changing the iframe src after fetch/catch as above may resolve the issue?