set-constant is unstable in version 1.45.3b15

[dimisa-RUAdList]

Prerequisites

• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• using a new, unmodified browser profile.

Description

Example: rule player.smotrim.ru##+js(set-constant, pl.getParams.isPlay, null) does not always work

A specific URL where the issue occurs.

https://www.m24.ru/

Steps to Reproduce

1. open https://www.m24.ru/
2. refresh the page multiple times

Expected behavior

playback in the player should be stopped

Actual behavior

playback in the player starts automatically

Configuration

uBlock Origin: 1.45.3b15
Chromium: 108
filterset (summary):
network: 103010
cosmetic: 59877
scriptlet: 17911
html: 0
listset (total-discarded, last-updated):
default:
user-filters: 0-0, never
RUS-0: 39580-11, now
easylist: 63793-65, now
easyprivacy: 30976-1282, now
plowe-0: 3678-905, now
ublock-abuse: 77-1, now
ublock-badware: 4176-109, now
ublock-filters: 31506-144, now
ublock-privacy: 254-1, now
ublock-quick-fixes: 422-14, now
ublock-unbreak: 1915-44, now
urlhaus-1: 7175-0, now
filterset (user): [empty]
modifiedUserSettings: [none]
modifiedHiddenSettings: [none]
supportStats:
allReadyAfter: 639 ms
maxAssetCacheWait: 360 ms

[dimisa-RUAdList]

The same issue with the player.twitch.tv##+js(set-constant, Object.prototype.disableAutoplay, true) rule is seen here: https://www.goha.ru/

[uBlock-user]

Autoplay cannot be reliably blocked by js variable, this has always been the case.

[dimisa-RUAdList]

Version 1.45.2 does not have these problems. As in all previous versions.

[krystian3w]

Looks as regression in favor Blob: gorhill/uBlock@0971025

[dimisa-RUAdList]

Completely inoperative rule: mail.ukr.net##+js(set-constant, Object.prototype.AdvertisingManager, noopFunc)

Example (authorization required): https://mail.ukr.net/desktop#msglist/f0/p0

P.S. In all the cases above, everything works fine in Firefox.

[dportvine]

I have the same problem. Gif

[gorhill]

Ok so Chromium should still use the old way while Firefox uses Blob.

[gorhill]

On my side, the video player is inside https://player.vgtrk.com/iframe/live/id/1661/showZoomBtn/false/isPlay/true/mute/true/sid/m24, which does not match your filter (player.smotrim.ru).

At https://www.goha.ru/, I don't see a player even without your rule.

[dimisa-RUAdList]

There is no broadcast on https://www.goha.ru/ now. But the check can be done in any other place where broadcasts are active, for example here: https://www.igromania.ru/

In the case of https://www.m24.ru/, geolocation probably matters.

One way or another, Firefox's CSP bypass method creates problems in Google Chrome.

[gorhill]

Ok I can reproduce at https://www.igromania.ru/. I find that scriptlet injection for Firefox is also less reliable with the Blob approach.

[dimisa-RUAdList]

I have quite a large feedback on ABP + Firefox and I have not yet come across complaints about non-working scriptlets. It uses a similar way to bypass the CSP. In background.js ABP it looks like this (lines 19662 onwards):

// Firefox 58 only bypasses site CSPs when assigning to 'src',
        // while Chrome 67 and Microsoft Edge (tested on 44.17763.1.0)
        // only bypass site CSPs when using 'textContent'.
        if (typeof netscape != "undefined" && typeof browser != "undefined")
        {
          let url = URL.createObjectURL(new Blob([exec]));
          script.src = url;
          document.documentElement.appendChild(script);
          URL.revokeObjectURL(url);
        }
        else
        {
          script.textContent = exec;
          document.documentElement.appendChild(script);
        }

[gorhill]

I am trying ABP and I see the Twitch feed being autoplayed with RUAdList.

[dimisa-RUAdList]

There are no such rules in RU AdList for ABP. They only allow scriptlets from abp-filters-anti-cv, and only for limited purposes. However, you can add this rule manually for validation purposes. In ABP syntax, this would be: player.twitch.tv#$#override-property-read Object.prototype.disableAutoplay true

[gorhill]

On a related note regarding disabling autoplay, maybe it's time for uBO to support for Permissions-Policy through a new filter option that would work like csp= -- Permissions-Policy supports disabling autoplay through autoplay 'none'. If this works as documented, this sure would be cleaner than doing this through set-constant.

[uBlock-user]

maybe it's time for uBO to support for Permissions-Policy

For Chrome, it's desperately needed as Chrome offers not a single option to disable autoplay for users.

[krystian3w]

So this is deprecated: https://chrome.google.com/webstore/detail/autoplaystopper/ejddcgojdblidajhngkogefpkknnebdh (MV2 should works to June 2023, harder to December 2023).

Some of the stuff is dropped on the addons e.g. RSS on both.

[dimisa-RUAdList]

For version 1.45.3b16

In Google Chrome, set-constant works stably, the rules do exactly what is intended.

Firefox
Scriptlets remained functional, CSP bypass is correct, there are no error messages about scripts embedding in the console.

As for the possibility of a cleaner shutdown of autoplay, then of course I welcome this.

[gorhill]

Permissions-Policy supports disabling autoplay through autoplay 'none'

I have an implementation of permissions= filter option and using *$permissions=autoplay=() does not prevent the video from playing (tried in Chromium), even though I can see the Permissions-Policy header being properly injected. As per this page, this should work, but it does not work, at least for the case here.

So not sure at this point a permissions= filter option is worth it.

[krystian3w]

Maybe pages simulate poc in own js libraries.

https://gomakethings.com/how-to-simulate-a-click-event-with-javascript/

[uBlock-user]

does not prevent the video from playing (tried in Chromium),

Were there any user-gestures from your side ?

[MasterKia]

https://developer.chrome.com/blog/autoplay/#new-behaviors:

Autoplay with sound is allowed if:
* The user has interacted with the domain (click, tap, etc.).
* On desktop, the user's Media Engagement Index threshold has been crossed, meaning the user has previously played video with sound.

[gorhill]

autoplay=() is suppose to require a user gesture, the browser can't be fooled by JS -- the isTrusted should be false when event is dispatched programmatically.

[gorhill]

https://developer.chrome.com/blog/autoplay/#new-behaviors

That link is older than the one I posted, so I assume the more recent one is more accurate about what is supposed to happen.

[uBlock-user]

As per https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/autoplay --

Specifically, where a defined policy blocks use of this feature and there were no user gestures, the Promise returned by HTMLMediaElement.play() will reject with a DOMException. The autoplay attribute on and elements will be ignored.

[gorhill]

I think they are just saying the a less restrictive policy can't override a more restrictive one. Anyway, I found that MDN documentation re Permissions-Policydoes not seem up to date, hence I have been looking elsewhere, i.e. https://www.w3.org/TR/permissions-policy/ and https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.

[uBlock-user]

Never seems to have worked - w3c/webappsec-permissions-policy#276

[krystian3w]

Related: #2714