Not entirely sure if it is a bug or if this behaviour was intentional however it has changed recently as QF used to function differently.
The IE browser back button used to take you back to the previous page in a completely normal fashion. However, recently it no longer does that as when some pages are loaded they appear to be loading several times.
For example: When I click the “magnifying glass” icon to look at transactions associated with any nominal account code, a single click opens the page in the same tab to view the correct nominal code list. If I then click Back from the browser toolbar (or my extra mouse button to go back) it no longer works. You can see what the browser thinks has happened here:
The current page was one click from the chart of nominal accounts to the current page, but to go back is 4 clicks.
It’s not isolated to IE, on some pages due to the way we use a HTML5 feature called pushstate, it prevents the browser back button from working normally.
This I’m afraid is a consequence of allowing the back button to also land you on the correct page index for when you drill down onto items. So when you land on certain pages it appends the index to the URL (o=0), hitting the back button once removes the index, hitting it twice quickly does take you to the original screen. To save the bother I would instead recommend using the back button on the page.
It’s a bit of a pain, but I understand you were asked to make the change. I use my mouse’s back button all the time as it speeds up my work and this is frustrating as it is not just a double-click but mostly 4 clicks to go back.
Is the HTML5 pushstate something we could have an account setting for please, maybe a tickbox to enable/disable it?
This is something I have been meaning to look into/mention. I use the buttons on my mouse for page navigation, or sometimes the keyboard. I don’t see why we need to use hardcoded links on pages to move around the site reliably.
I’m pretty sure there are other sites that do this but also leave client side navigation working correctly. Maybe they are using something other than pushstate?
This is the power of the community! Thanks to Ian for the knowledge and you guys for looking into it again and resolving it speedily… although it has taken a few days and not the normal couple of hours it usually takes - I guess your standards must be slipping!
We used to be able to just fix stuff up and deploy in 5 mins, although it’s not so easy any more. Deployment is much slower as we have multiple load balancing servers, so we batch together updates. Also in this case it wasn’t originally looking like a quick fix, until @ian_roberts helped out.
By the way you can always see when we last updated by referring to the build number at the bottom of every page: