Google Chrome to stop back-button hijacking
chromium-review.googlesource.com
chromium-review.googlesource.com
Anyway, I approve of this change.
The commit doesn't include a mechanism for marking the should_skip_on_back_forward_ui flag, but the normal way Chrome verifies "user's intention" is waiting for a gesture/click in the page.
So if you're doing front-end routing in response to a user clicking on a link or button in your UI, or swiping the page or what have you, that will allow you to pushState and then intercept the back button, as you can today.
But if you attempt to pushState on load, that's not enough to establish intention; the back button will then skip your pushed states and leave the page.
Browsers will probably never be clever enough to tell which clicks had "the right kind" of intention. The arms race continues!
This is much better then the current solution where you have to long-clicking the back button and manually pick a safe entry.
"why would someone abuse this" shows an incredible naivete. Anything that can be abused will be abused.
There was a kind of "if we don't expand the web platform, native apps from walled-garden app stores will take over" discourse at the time, from all browser implementors — less so from Apple, which could hedge its bets with the App Store.
Talk video here: https://www.youtube.com/watch?v=QFZ-pwErSl4 Source code here: https://theannoyingsite.com/index.js
Well done.
Don't open this site with 'reopen tabs after crash' option activated!! How can they even popup so much and how can the print dialog disable closing buttons??
Looking at the video, Chrome and Safari are in no way better off. Still, I thought popups were fixed 2008.
It still managed to go full screen and play audio in the form of Nyein cat and some text to speech, which admittedly was annoying. But I managed to close the site and any "popup" tabs it made with two actions: Alt+F4 (I'm on Windows) followed by clicking "leave page". I had opened the site in its own window so my existing tabs were unaffected, but I wouldn't have been much worse off if I hadn't.
I believe Safari has an option to send all popups to tabs rather than new windows, so it is probably affected to a similar (low) level as FireFox. But I don't believe that Chrome has this option.
This is worse than I thought.
What I do (for different reasons, but would still be effective) is to not allow Javascript to execute. Sites that are so poorly designed that they cannot operate without Javascript enabled are sites I simply don't use.
Is anyone keeping an annotated list of annoyingsite techniques, to see what's still broken?
I'd love to gaze at the medusa, but indirectly if at all possible.
(Caveat: I'm not sure if this change is being committed by a Google Chrome dev or non-Google Chromium dev)
Chrome > Warn before quitting (cmd+q)
I've disabled cmd+q on my system, so I haven't run into this recently.
It's not the only reason chrome has become a not-so-good citizen on macOS: the memory/CPU footprint is bad enough, but it also does things like give system-like popups when a new printer is detected on my network. I'm not sure when I permitted chrome to do this, and it seems like it's trying to subsume more and more of my system's function without asking. I find the command + q thing to be a particularly annoying version of this.
- warn before navigating
- give options for the keyboard shortcut
- change shortcut unilaterally
They chose the third, which some (likely the overwhelming majority) preferred. I didn't, so I switched to Firefox. We're both happy this way I guess.
This requires too much page context. A search field being partially filled is very different than a long registration form being worked on.
>give options for the keyboard shortcut
You said yourself, they released an extension for this.
Oh was there an official one? At the time, the only extension I could find was some slightly-sketchy third party one that allowed you to set hot keys for many things.
> This requires too much page context. A search field being partially filled is very different than a long registration form being worked on.
Fair enough.
Yes, Google released an official extension to coincide with the update that removed the hotkey.
https://chrome.google.com/webstore/detail/go-back-with-backs...
Alternatively, the browser could just play it safe. I recall at one point the old Opera would prompt if unsaved form edits were present, on any navigation attempts (clicking away or browser back button/backspace). This saved me on many occasions and I never remember being annoyed by over-notification.
Firefox does it to.
This has saved me many a time when I've accidentally done a back gesture on my Magic Mouse while composing an HN comment.
In a nutshell, it feels like browser makers do their best to improve user experiences, and website designer do their best to ruin it again.
Some websites just log you out if you press the back button.
https://chrome.google.com/webstore/detail/go-back-with-backs...
For me that's not the biggest Chrome deal-breaker anyway (besides privacy), as Chrome doesn't support stack-like behavior for switching tabs with ctrl-tab.
(I also use BetterTouchTool to add similarly simple gestures for open-in-tab, close-tab, switch between tabs, and go-to-top/bottom)
What I hate and is much more common is the "do you want notifications". I'd love a "never ask about notifications again" option.
Just set it to "never ask" or something similar and it will auto-deny all notification permission requests.
You can also enable it for specific sites if you want.
People don't read dialogs, they just don't. And giving them the option of "never ask again for any site" would most likely mean that some would hit it and it wouldn't even register that it was something they did, let alone remember they did it for the rest of their time using that browser.
Then you start getting complaints about how Firefox has this notification feature but chrome doesn't, or notifications are broken on my chrome, or whatever else.
That's why I'm hopeful for some new browser APIs which will manage permissions across the board, and will use things like heuristics to allow or disallow asking for permissions based on things like amount of interaction, number of times they interact with the website, and the "kind" of site it is (a PWA should be allowed to ask for notifications fairly early on in the process of using it, a news website should have to wait until the user has come back at least a few times before being able to ask).
I don't envy browser vendors for having to make decisions on what is and isn't allowed there, because no matter what some well meaning sites will be caught in the crossfire, but it's by far the "least bad" solution in my opinion.
The problem is that there's lots of content the publisher thinks is notification worthy, but not the user. No, I don't need a notification every time you post to RandomNewsSite.com.
That would still annoy the hell out of me.
My default is now "select all, delete"
That’s why they invest heavily in Chrome (and FF, to some degree), and work on all sorts of APIs like notifications, WebAudio, etc.
The decision process is probably not far off from “could a sandboxed, locally installed, native app do this?”
Turning notifications off by default would probably err to far on the other side. At the very least, they would want some noticeable UI indicator that notifications are available. I could also see it becoming a feature only available to sites after x visits/y days.
It'd be interesting if browsers had a default setting that didn't allow a site to ask for notifications until you had switched to the tab and left it open a handful of times, or if they expired notifications automatically after you hadn't been to a site for a few days. It would also be interesting if they only allowed them for "pinned" tabs.
For those trying to find it. It's settings -> advanced -> content settings -> notifications.
So you can turn off the top slider from "ask before sending" to blocked. Probably a good time to check your "allow" list on the same page. My blocked list is about 100 long.
Notifications can be disabled as explained here: https://blog.mozilla.org/firefox/no-notifications/
PS: for example, quick screenshot from one news site with notifications: https://imgur.com/a/zWdJqMo
In the old days, you needed an RCE and some malware to do desktop popups. Now it's apparently just a feature. It's becoming an increasingly abused function.
Seriously, ad&tracking blocking is the first thing I do when I have to fix up a computer for a friend or family member.
Evil
Once you're aware of it, it's simple enough to hold the back button and then go back several entries at once, but maybe this change will remove the "when I hit back, it goes back and then forward to where I was when I hit back" behavior in the first place.
I believe this is one of the intended effects. For example, when you click on a link after a Google search, and then click the back button to go back to the search results, I imagine Google records this to downrank that page for that query in a small way. When you kill the tab, you forfeit this opportunity.
You accidentally click "clickfarm.com" from, say, google.com; then you press back button, it seems that you are "back," by the moment you click on another link, you realise that google.com page was fake, and is stuffed with invisible ads.
What they look above all else are the organic clicks from clear IP ranges.
Accessible navigation patterns are a key part of making the web accesible to decentralized improvement. If every SPA was a black box with its own navigation regime, the web would regress to walled garden apps that characterize 90s desktop and early iOS ecosystems.
>It allows them to use their own tools for bookmarking, link sharing, and history management rather than forcing a from-scratch experience when they come to the sites.
Such as the behaviour of buttons outside the sandbox the browser provides? To quote you:
>browsers haven't been stateless url-loaders since the late 90s
Why break the expectations of the back button to hack the other tools to work how you'd expect when, really, all of the features you're describing worked perfectly fine before SPAs. The very reason pages like this frustrate me are because they don't work with the history management I expect.
Regarding your opinion, I'm still not sure what you are comparing / suggesting.
Are you saying that late 90s reactivity on the web was good enough? I think you are very much in the minority on that one.
Are you saying SPA authors shouldn't expose URLs for different navigation paths to the browser? I think you would be surprised at all the places your browser experience breaks, like not being able to restore tabs, or copy links to interesting news stories.
The right way to do SPA is to design nav actions that feel like links, and only update the history in those. A user not watching carefully for page refreshes or net traffic shouldn't be able to tell the difference - and perhaps there are times this is happening on your browser that you aren't aware of because it can be done smoothly.
Websites as apps will continue to work, they'll either lose this functionality or use normal links - the kind that are good enough for Facebook et al. Or for Hacker News.
>Are you saying SPA authors shouldn't expose URLs for different navigation paths to the browser? I think you would be surprised at all the places your browser experience breaks, like not being able to restore tabs, or copy links to interesting news stories.
No. All of these work with links. Aren't you trying to fit a SPA shaped piece in a website shaped hole?
As a concrete exampke, rich news experiences that let you scroll through preloaded stories benefit a lot from not needing to re-render all of the surrounding layout when the content changes, and from assigning a different url to each story.
Btw, I never said this was worth the current trade-off with malicious sites, just that the history features were originally inspired and still used by honest sites. Fortunately we have better options than all or nothing; sounds like Chrome is implementing a heuristic that makes sure url history can only be updated in some proportion to human actions. Another option might be a whitelist check like "<site> would like to update your history".
https://bugs.chromium.org/p/chromium/issues/detail?id=907167
That said, I would be in favor of an option to disable it globally, or for certain domains.
It's a clever mechanism but malicious sites tend to just attach a click listener to the page and trigger everything when the user clicks for the first time.
On the other hand it can also be a pain to program around this if you need it. Say you have a webapp that allowed you render an image then display it in a popup. But the rendering is time consuming, so you do asynchronously in the background. The user clicks the button and you start the render. When the render is complete you try and open the popup, but your now in a different task where the popup is blocked. The best way to work around this is to display a modal dialog, saying that the render is complete. Then when the user hits "ok" you can use the task that the event created to display the popup. But it might confuse the user why they need to confirm the render is complete.