Skip to content

Back button/history broken in Firefox on reference pages #822

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
antiboredom opened this issue Apr 29, 2025 · 6 comments · Fixed by #844
Closed

Back button/history broken in Firefox on reference pages #822

antiboredom opened this issue Apr 29, 2025 · 6 comments · Fixed by #844
Labels
Bug Something isn't working

Comments

@antiboredom
Copy link
Member

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 antiboredom added the Bug Something isn't working label Apr 29, 2025
@antiboredom
Copy link
Member Author

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

@andysmith26
Copy link

confirmed in Linux Mint with FF 138.0.1

@andysmith26
Copy link

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 withastro/astro#11919 ?

@ksen0
Copy link
Member

ksen0 commented May 10, 2025

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
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants