Portal floods browser history

[ascheucher]

I am new to the really awesome project and wanted to take a first look... Opened the portal and wanted to take a look how much data is available for my city.

Then I took a look into my browser history to open the newspaper article from where I came to the project page. The history was flooded with hundrets of portal map URLs like this:

https://portal.openbikesensor.org/map#12.25/47.04048863606971/15.482881147377078
...
https://portal.openbikesensor.org/map#12.25/47.04412825564175/15.479705459772367

This is not acceptable!

Please don't break other people's local tools!

Maybe just add the first one and then only URLs which have not changed for some time like 10 or 20 seconds. The user really doesn't want to have every URL during his scrolling and zooming actions.

[gluap]

As far as I know this is a common feature among map sites. Try for instance openstreetmap.org which exhibits the same behavior. Even google maps does this.

Why is this? Users want to be able to share their map view by sharing the address from the browser either via copy and paste or the sharing button in the browser. To achieve this the address bar is updated. However it is done in a way that keeps the back button pointing to the previously visited page - hence not breaking its behaviour.

I wonder what local tools rely on the history being sparsely populated, if it is something commonly used one might ponder whether it beats having an intuitive shareable address bar.

edit to add: I wrote the above on my mobile where a quick test didn't show the obs map to be overly spammy. It's much more noticeable on the desktop though.

[opatut]

Our portal behaves a little different to Google Maps and openstreetmap.org, as it does change the browser URL on every animation step while dragging the map around, not just when stopping. I explicitly used History.replaceState so that it would not mess with the browser history as much as History.pushState. The replace is not adding a new entry to your browser's "back" history, which is awesome, as then you can go back to the previous site easily without moving back along your dragged viewport first. However, I was unaware that each replaceState call does indeed write into browser history. This is IMO a weird behaviour by the browsers, as it is described as follows:

Updates the most recent entry on the history stack to have the specified data, title, and, if provided, URL

I would not expect it to appear multiple times in the "browser history" then either, but apparently the browser history and window's "history stack" are not the same.

I'll try to change the behaviour to be more in line with google and OSM, though it might be tricky.

[ascheucher]

That was fast. Thanks for fixing!