Why does Discourse fill my Safari history?

In a couple of hours viewing I got 160 entries. Today ten or fifteen minutes of exploring left about 60 entries using Safari 6.0.5. Is it necessary for Discourse to work this way? I certainly can’t imagine my ever wanting use history to get back to a topic and all that clutter makes it more difficult to maintain my history file and to find the entries I might actually want.

I have noticed one or two other websites that do this but for the most part others just record the initial address used to get to the site.

If it’s possible to stop this it would certainly be OK with me.

Also, I haven’t looked yet with Explorer to see what happens there.

@sam you may be interested in seeing this

This happens cause of the way we use replace state. As you scroll through topics we “track” your location by updating the URL. If you are looking at post #15 the URL updates automatically to post #15. This makes sharing what you are looking at trivial.

There are two side effects, history pollution and favicon flickering in chrome.

We would certainly consider adding a knob to disable the “auto updating of urls while browsing” or maybe use #locations instead in topics (optionally)

How much historical granularity are you wishing to get rid of?

Do you want to only see http://discourse.mcneel.com once when you start browsing, and nothing from then forward?

Or do you want to see each new topic you visit as a separate history entry, but not each reply to each topic? As Sam mentions, when you scroll down the URL changes to show the address of the page you’re currently viewing.

Even with GMail, when the part after the # in my URL changes, a new history entry appears (that’s how they track changing messages from the inbox).

My personal preference would be to just see the one startup entry. However I can’t even guess what this would do to the workings of Discourse or whether Discourse would have alternate ways of accomplishing the tasks for which it is currently using history pollution as a tool.

If I understand correctly, the newsreader approach downloads all the messages to the client, which is supported by a dedicated-purpose client app which maintains the user-specific administrative data locally in it’s own dedicated database. Discourse, on the other hand, wants to maintain it’s data at the server end and (mis?)uses a general-use browser feature to support some of the client-specific administrative functions. In the process it seriously impacts the general usability of the browser feature for it’s intended use. Is this a fair summary?

I realize that keeping data at the client end in a Discourse-specific file is a can of worms that makes cookies look like your fairy godmother, but perhaps more experienced people can come up with something that makes it all good. Can’t Discourse maintain this info for each user at the server end? Unlogged-in users for the duration of the session, others between sessions?

Maybe a good first step would be to provide the knob Sam mentioned and see what people have to say about the side effects when they turn it off.

That’s how it behaves on my mobile phone running IE…
Side effect of that is that you can’t use arrow back as that closes the application.

Only IE10 or later supports JavaScript manipulation of the address bar. It’s supported in many older versions of Firefox, Chrome, Safari, Opera though.

Looks like this is in fact the same in Chrome, if you view History, you’ll see a list of the URLs as they changed.