BehindTheOverlay
BehindTheOverlay copied to clipboard
NicolaeNMV
BTO fails to block Stackexchange's and Serverfault's overlays (example code included)
BTO fails to block the following overlay:
<html><head>
<link rel="stylesheet" type="text/css" href="https://cdn.sstatic.net/Shared/stacks.css">
</head>
<body>
<div class="ff-sans ps-fixed z-nav-fixed ws4 sm:w-auto p32 sm:p16 bg-black-750 fc-white bar-lg b16 l16 r16 js-consent-banner">
<p>Un-blockable overlay</p>
</div>
</body></html>
To see popular examples of it, visit the home page of Serverfault, or visit the home page of Stackexchange and click on any question. The floating dialog box is displayed regardless of whether Javascript is enabled in your browser, but in either case, you must first clear or disable cookies.
No, not a dup of #32. For #33, manually clearing/disabling cookies to trigger Serverfault or Stackexchange to display the un-blockable overlay is incidental. If you paste the example code I gave into a local html file and open it in a browser, you'll also get the un-blockable overlay, regardless of whether you cleared or disabled cookies.
Hi @learnoverlay, thanks for the report. Unfortunately this is not what this extension considers an "overlay". Currently an "overlay" it's something that covers the whole page and prevents the user to see the content and blocks the scrolling. A cookie box on stackexchange on the left handside doesn't do that. So it's hard to come with an heuristic that would work on all the websites. Currently this extension doesn't have any site specific rules. It's one heuristic for all the website.
I'd call the general desired behavior "absolute scrollability": an option that, when enabled, unconditionally forces every pixel in the window to scroll when keyboard or mouse scroll commands are given, regardless of which parts of the web stack generated those pixels. One rule would suffice to cover all elements for all websites; simply ask for each element: "Does this element scroll, or not scroll, when user scroll commands are given?" Two selectable modes for absolute scrollability would be useful: either render the anti-scroll elements statically, and force them to scroll, or (like BTO currently does for full-screen overlays) just block all anti-scroll elements. I guess a possible way to do this would be to look at each element's window position before and after a scroll command is given; if the window position remains unchanged, then the element is anti-scroll, and therefore subject to staticization or blocking. Dunno if this would be practical for BTO.