Does this mean websites can now hijack android’s OS-level back button? In addition to hijacking the browser level one?

I hate when I hit back, but instantly redirect to the same page. This is so frustrating when it happens. And it happens even on major sites. (Microsoft’s official community “answers” forums have given me this issue lately. Fills up search results and then traps you there)

Kind of. There is a mitigation in the spec https://github.com/WICG/close-watcher#abuse-analysis

Briefly, the user may need to press back a couple times in order to escape, but the maximum number of presses needed is bounded and is dependent on how much the user interacts with the page. Of note, closing the tab bypasses this API entirely, at least according to that page.

Usually my back button on my phone already just does the browser back functionality when the browser is open, which does mean it gets hijacked. Sometimes if I mash the back button enough I'll manage to sneak a trigger throughout whatever dumb thing the site implemented to try to stop me though, so I'm loath to give them any other tools to try to detect this.

Long press on the back button usually works

(I don't know if it is OS-level.) If you have the GitHub Android app installed, GitHub links open in the app. In the app, swiping right (back) takes you to the app's home screen and not to where you clicked the link (e.g., the HN app). The same isn't true for many other apps.

Also, GitHub team, could you make your app better? It has so many little annoyances.

I'm seeing this a lot with news sites, they'll redirect your back press to a page screen with bunch of click bait headline/images. Some of them are pretty disturbing at first glance, seems like they're trying to get shocking images in front of you to keep you engaged. I think they're trying to fight against news aggregators but it's such a shitty idea.

The funny/sad thing is the folks adding this functionality are probably reading my comment. You should be ashamed of yourselves.

A more evil version of this is detecting which news aggregator sent you there, then making that clickbait page look like the source aggregator. I've seen this with the news feed from Chrome on Android, clicking on a store then going back I thought I was back on the news feed but the stories just didn't look right.

This could totally be used for phishing, right? Open a link in gmail -> go to nasty site -> press back and see google login page that's actually still the nasty site. Browsers should prevent cross origin sites from seeing where the visitor came from (i.e. clear referrer).

Also, why doesn't the back button disable any automatic (non-user initiated) redirects on pages loaded that way? Seems like an obvious fix to the history loops we keep seeing.

Websites have a lot of control over referrer headers these days.

Often, news aggregators add to urls so the site knows where it came from, or it’s using a feed that already has that.

Now, that said, in an email, you can send links that encode that it’s coming from email, but you would get caught by the non-gmail using people suddenly seeing fake gmail.

The pessimist in me says that most will probably try to log in anyway.

Ah, the ye olde chum bucket

The <details> name attribute example doesn't actually use the name attribute? Am I missing something?

They added it in the YouTube video but forgot it in the post https://youtu.be/oqCsXbsuvM0

I noticed this, as well. AI-generated code? (It's hard to imagine a human setting up that code and forgetting about the very thing they are attempting to demonstrate.)

I thought I was missing something. But then I came looking for confirmation. Does this mean I may have what it takes to make it in webdev?

I noticed the same thing. I believe it's all unintentional omission.

Maybe it's inferred with the built-in Large Language Markup

> CloseWatcher API

> Chrome 120 brings the solution with CloseWatcher, a new API for directly listening and responding to close requests.

> watcher.addEventListener("close", () => document.querySelector("#sidebar").classList.remove("open"));

Couldn't they add an HTML attribute onCloseRequest?

Slightly related, I wish there was an attribute "onClickOutside" so we could close modals and dropdown menus without manually adding an event listener on the window and checking if the click wasn't inside the element.

The issue with a single global event handler is discussed here: https://github.com/WICG/close-watcher#a-single-event

If you use popover="", you get the kind of functionality you're discussing for free. For <dialog>, the discussion is in progress and reaching a conclusion: https://github.com/whatwg/html/issues/9373

I don’t think I ever like accordions where you can only have one item open at a time. So often I just want to open them all, and probably wish you hadn’t collapsed them in the first place. Well, at least if people start doing it this way I can make a simple user script to just remove name attributes from <details> elements.

I wish I'll be able to use the CloseWatcher API to replace my history API hack to close dialogs. As always, we're now waiting for browser support

>Permission policy violation reports

How about my User Agent working for me instead? and doing exactly what I want and not some web page?

Yet another reason to use something other than Chrome.

Why?

Can't speak for OP, but Google pushes through too many "standards" that are just "Do what Chrome already pushed to prod, or else users will think your browser is broken". Could be the same thing here