New in Chrome 120 back button detection

Does this mean websites can now hijack android’s OS-level back button? In addition to hijacking the browser level one?<p>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)

The &lt;details&gt; name attribute example doesn&#x27;t actually use the name attribute? Am I missing something?

&gt; CloseWatcher API<p>&gt; Chrome 120 brings the solution with CloseWatcher, a new API for directly listening and responding to close requests.<p>&gt; watcher.addEventListener(&quot;close&quot;, () =&gt; document.querySelector(&quot;#sidebar&quot;).classList.remove(&quot;open&quot;));<p>Couldn&#x27;t they add an HTML attribute onCloseRequest?<p>Slightly related, I wish there was an attribute &quot;onClickOutside&quot; so we could close modals and dropdown menus without manually adding an event listener on the window and checking if the click wasn&#x27;t inside the element.

I don’t think I <i>ever</i> like accordions where you can only have one item open at a time. So often I just want to open them <i>all</i>, 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 &lt;details&gt; elements.

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

&gt;Permission policy violation reports<p>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.