Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

BTO fails to block Stackexchange's and Serverfault's overlays (example code included) #33

Open
learnoverlay opened this issue Jul 19, 2021 · 4 comments
Open

BTO fails to block Stackexchange's and Serverfault's overlays (example code included) #33

learnoverlay opened this issue Jul 19, 2021 · 4 comments

Comments

@learnoverlay
Copy link

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.
@TheTechRobo
Copy link

dupe of #32?

@learnoverlay
Copy link
Author

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.

@NicolaeNMV
Copy link
Owner

NicolaeNMV commented Jul 22, 2021 •
edited
Loading

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.

@learnoverlay
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@NicolaeNMV @TheTechRobo @learnoverlay