@othermaciej There's another thing I always wanted to have to solve another subset of troublesome popups, but it might be a bit out of scope (?) - to be able to "deactivate" a CSS class on the page as if it wasn't there - so if a script adds e.g. ".noscroll" to body which sets overflow:hidden, I can disable that .noscroll class and reenable scrolling

@mackuba specifically from a content blocker you want to do this? Not from within a web page?

@othermaciej hey, sorry I didn't respond, I had to recheck how this all works…

I'm trying to stick to content blocker only. Injecting scripts would solve a lot of things, but it also adds this scary permission warning (even if it's only CSS and not JS, I think - can you actually do what it says if it's only CSS?).

I think people feel safer if they know my extension can't inject anything there. Just this week Chrome told me that an extension I had installed has become a cookie-stealing malware…

@othermaciej without injecting JS/CSS to the page, there are a few categories of popups I can't deal with using just a content blocker & css-display-none:

1) unmarked/obfuscated class - `:has` will hopefully fix some of those
2) blocks scroll by setting overflow:hidden/position:fixed via style="…"
3) blocks scroll behind popup using a class that does the same

Something new in content blocker API could help with 3, probably not 2. Although objectively, I guess it might be a too niche feature…

@othermaciej I've checked how it looks with Web Extensions, but it seems it looks even more dangerous than an App Extension with injected CSS, because you have to first enable the extension and then manually grant it access for all sites, and then there are exclamation mark signs everywhere…

@othermaciej I made this monstrosity now and it works on that site too 😅 Should I be worried that this may be too complex and affecting performance somehow, or is this all super optimized behind the scenes?

@sto3psl I think you can feature test this directly by trying to make a GL context for an OffscreenCanvas - it will error out if this combo is not available.

@othermaciej I tried and it doesn’t error 🙈. I still get a GL context from the OffscreenCanvas but everything renders broken (because the feature is not ready, I guess).

@sto3psl This was a bug in an earlier beta. The intent is that OffscreenCanvas will not support "webgl" contexts regardless of whether it's on a worker. Expect to see that fix in an upcoming beta, it should allow for easier feature detection. (Sorry, I didn't realize it hadn't been in a beta yet). https://bugs.webkit.org/show_bug.cgi?id=253267

@othermaciej that sounds great, thanks. Is there an ETA for „webgl“ OffscreenCanvas? 😅
Oh and I don’t have permission to see the linked issue.

@sto3psl Sorry about that, it’s restricted for technical reasons I can’t fix right now but the upshot is to disable “webgl” for main thread OffscreenCanvas.

I can’t share when actual support for WebGL OffscrenCanvas is coming but it’s something we are interested in.

@AshleyGullen we are evaluating this, but it’s likely we will still ship the 2D support before 3D. We believe it is conforming per spec to support OffscreenCanvas without WebGL. And it should be feature detectable (just try making a gl context in an OffscreenCanvas and see if it fails). How much is the impact to update the feature test?

@othermaciej We already have updated it, but it affects all content published by users of our app for the past couple of years, and they will all need to re-publish their content to avoid being affected. It's a collossal job to ask everyone to do that and I would be surprised if even 10% of customers did that prior to the Safari release.

@othermaciej We did add feature detection, but only for the existence of OffscreenCanvas, because we did not anticipate anyone shipping only some contexts. Since Safari supports WebGL in OffscreenCanvas in the DOM it is not actually possible to feature detect this prior to creating a worker, which makes feature detection even harder

@othermaciej I can't understand why Apple would do this - what did they expect to happen to all existing OffscreenCanvas WebGL content? Why not postpone it for a release and ship with WebGL support to be on the safe side?

@AshleyGullen @othermaciej

Postponing makes sense here. It's not like we haven't already waited ~4 yrs for this to hit FF and Safari ;)

https://caniuse.com/offscreencanvas

(I would love 2d support but if shipping only 2d means things will break, I can wait)

@rgadellaa @AshleyGullen I'm not able to discuss scheduling questions in detail on Mastodon. If anyone is aware of breakage besides the Construct framework, let us know, so we have all the relevant information.

@AshleyGullen This was a bug in an earlier beta. The intent is that OffscreenCanvas will not support "webgl" contexts regardless of whether it's on a worker. Expect to see that fix in an upcoming beta, it should allow for easier feature detection. https://bugs.webkit.org/show_bug.cgi?id=253267