Age | Commit message (Collapse) | Author |
|
|
|
Port 216dbaedaf587db834cfdd53b896e9c7e1284d9c to glitch-soc
Signed-off-by: Claire <claire.github-309c@sitedethib.com>
|
|
Port 81e1cc5fece9a431c28ca648c2dd4b1b5f643f13 to glitch-soc
Signed-off-by: Claire <claire.github-309c@sitedethib.com>
|
|
Port f54ca3d08e068af07a5b7a8b139e7658b3236db8 to glitch-soc
Signed-off-by: Thibaut Girka <thib@sitedethib.com>
|
|
Port 0f07218e53bf581127cdcf5fbf12d9c207ace8d7 to glitch-soc
Signed-off-by: Thibaut Girka <thib@sitedethib.com>
|
|
So far, glitch-soc used history.length to decide whether to call `goBack()` or
go to / in order to not leave the webUI. This made clicking the “Back” button
go to the “Getting started” column instead of going back in the browser's
history when such an action would leave the web UI, but also when:
- The WebUI is refreshed (F5)
- A tab is restored
- The history length reaches its maximum (e.g., 50 in Firefox)
This commit fixes these shortcomings by checking `window.history.state`.
Indeed, we only want to go back in the browser's history when the current
location has been reached from within the WebUI, which only happens via
`pushState` as far as I know. Since browser store the serialized state in
the browser history, this also survives page reload and session restoration.
|
|
|
|
|
|
|