`trusted-click-element` does not re-trigger after SPA navigation

[JoviDong]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
• 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

I'm using trusted-click-element to auto-click the high-quality "trial mode" toast on Bilibili for unlogged users.

www.bilibili.com##+js(trusted-click-element, '.bpx-player-toast-wrap .bpx-player-toast-confirm-login, .bpx-player-control-wrap .bpx-player-ctrl-quality-menu-wrap .bpx-player-ctrl-quality-menu-item[data-value="80"]', !cookie:/^DedeUserID=/)

The primary issue is that trusted-click-element only triggers once. It works perfectly on the first video, but when clicking a new video on the same page (SPA navigation), the scriptlet fails to click the new toast.

To test this, I used a Violentmonkey script to hook Object.defineProperty and Object.defineProperties to force-enable the trial mode for every video (since set-constant / trusted-set aren't suitable for this specific scenario). With the hook active, the toast successfully appears on the new video, but the click rule does not click it.

www.bilibili.com##+js(trusted-set, Object.prototype.expStore.isLoginTrialToastExpActive, true) // might break some features.
www.bilibili.com##+js(trusted-set, Object.prototype.isLoginTrialToastExpActive, true) // not work for this case.
www.bilibili.com##+js(trusted-set, Object.prototype.isViewToday, true) // not work for this case.

Questions:

1. Is it possible to update trusted-click-element so it re-triggers after SPA navigations?
2. If not, would you ever consider adding a set-desc trusted-set-desc scriptlet for scenarios requiring Object.defineProperty, Object.defineProperties hooks?

example.com##+js(set-desc, ownerMatch, propMatch, descMatch(get/set/value), constant(replace the get/set/value))
example.com##+js(trusted-set-desc, ownerMatch, propMatch, descMatch(get/set/value), constant(replace the get/set/value))
www.bilibili.com##+js(trusted-set-desc, , isViewToday, isLoginTrialToastExpActive, trueFunc)

Feel free to close this if it's out of scope or if there are no plans for it. Thanks for everything you do!

A specific URL where the issue occurs.

https://www.bilibili.com/video/BV1CDYg69EGL

Steps to Reproduce

(Note: To reproduce this, you must use a userscript to hook Object.defineProperty, Object.defineProperties so the trial toast is forced to appear on subsequent videos. Without the hook, the toast will not show for the new video at all, so the click failure cannot be observed).

1. Open the URL in a private window (unlogged).
2. Add this rule:

www.bilibili.com##+js(trusted-click-element, '.bpx-player-toast-wrap .bpx-player-toast-confirm-login, .bpx-player-control-wrap .bpx-player-ctrl-quality-menu-wrap .bpx-player-ctrl-quality-menu-item[data-value="80"]', !cookie:/^DedeUserID=/)

3. Inject a script (e.g., via Violentmonkey) to hook Object.defineProperty, Object.defineProperties so the trial mode is forced on for every video.
4. Load the page. Notice the rule successfully auto-clicks the trial toast.
5. Click a related video on the right sidebar (triggers SPA navigation).
6. The trial toast successfully appears for the new video (due to the hook).
7. Notice the trusted-click-element rule does not click the toast this time.

Expected behavior

trusted-click-element should re-arm/trigger again for dynamically loaded elements after SPA navigation.

Actual behavior

trusted-click-element only fires once per page load.

Configuration

Details

uBlock Origin: 1.74.1b7
Firefox: 158
filterset (summary):
 network: 0
 cosmetic: 0
 scriptlet: 0
 html: 0
listset (total-discarded, last-updated):
 removed:
  ublock-filters: null
  ublock-badware: null
  ublock-privacy: null
  ublock-unbreak: null
  ublock-quick-fixes: null
  easylist: null
  easyprivacy: null
  urlhaus-1: null
  plowe-0: null
 default:
  user-filters: 0-0, never
filterset (user): [empty]
switchRuleset:
 added: [array of 6 redacted]
hostRuleset:
 added: [array of 643 redacted]
userSettings:
 advancedUserEnabled: true
 cloudStorageEnabled: true
 cnameUncloakEnabled: false
 userFiltersTrusted: true
hiddenSettings:
 allowGenericProceduralFilters: true
 extensionUpdateForceReload: true
 filterAuthorMode: true
 trustedListPrefixes: ublock- user- https://raw.githubusercontent.com/JoviDong/
 updateAssetBypassBrowserCache: true
supportStats:
 allReadyAfter: 187 ms
 maxAssetCacheWait: 16 ms
 cacheBackend: indexedDB

[freezer2022]

Btw, also other (declined) SPA-related threads:

• redirect: Feature Request: SPA-aware built-in redirect scriptlet for reliable YouTube Shorts redirection #3676
• removeparam: removeparam is sometimes not applied when clicking on links #1704 + duplicates:
  • Sometimes the $removeparam= parameter does not work #1767
  • ublockorigin cannot filter the tracking params in url in some particular case (filter function -> $removeparam) #1951
  • Netflix URL parameters not removed on click #2498

[gorhill]

trusted-click-element is not meant to be used in a repetitive manner, if I understand correctly your use case, it's meant to execute a sequence of commands, and bail out at the end of the sequence. The scriptlet is primarily meant to address cookie walls.

[JoviDong]

trusted-click-element is not meant to be used in a repetitive manner, if I understand correctly your use case, it's meant to execute a sequence of commands, and bail out at the end of the sequence. The scriptlet is primarily meant to address cookie walls.

Thanks for the clarification! I see now that trusted-click-element is functioning exactly as designed for cookie walls and isn't meant for repetitive use.

To give a bit of context: on Bilibili, the trial mode resets whenever you switch to a new video via SPA navigation, causing the toast to reappear and require the click sequence again. I initially thought about suggesting a new parameter like stay, 1 (e.g., ... !cookie:/^DedeUserID=/, stay, 1) to keep the listener active. However, considering performance, complexity, and how niche this scenario is, I figure it's probably not worth adding new feature support just for this. Sticking to a userscript alongside uBO definitely seems like the more appropriate approach here.

Just one final question before we wrap this up: would you ever consider implementing scriptlets to hook Object.defineProperty / Object.defineProperties (e.g., set-desc or trusted-set-desc) in the future, to handle cases where set-constant isn't suitable?

Example concept:

example.com##+js(set-desc, ownerMatch, propMatch, descMatch(get/set/value), constant)
www.bilibili.com##+js(trusted-set-desc, , isViewToday, isLoginTrialToastExpActive, trueFunc)

Absolutely no worries if this falls outside the scope, isn't planned, or if you'd prefer to just close this issue. Thanks again for your time and all your work on uBO!

[gorhill]

Without the hook, the toast will not show for the new video at all

I don't understand: you want to get rid of these toasts, but these toasts do not appear without a special user script, so why use that user script in the first place if they cause the issue you want to solve?

[JoviDong]

Without the hook, the toast will not show for the new video at all

I don't understand: you want to get rid of these toasts, but these toasts do not appear without a special user script, so why use that user script in the first place if they cause the issue you want to solve?

Ah, I apologize for the confusion! My initial description definitely lacked the necessary context, which made it sound like the toast is an annoyance I want to hide. It's actually the exact opposite: I want the toast to appear so I can click it to unlock high-quality video.

To explain why the hook is needed, here is how Bilibili's system works:

1. Unlogged users are strictly capped at low video quality (≤360p). Trying to select anything higher triggers a hard login wall.
2. However, Bilibili offers a "trial mode" allowing unlogged users to experience higher quality.
3. The entry point for this trial mode is that specific toast (.bpx-player-toast-confirm-login). Clicking it activates the trial mode.
4. Once trial mode is active, the highest quality (1080p) becomes available. Clicking the quality menu item (.bpx-player-ctrl-quality-menu-item[data-value="80"]) actually selects that 1080p quality.
5. Bilibili restricts this heavily: you only get one trial per day, and it only lasts for 30 seconds (after which the video pauses and forces a downgrade back to 360p).

Because of these restrictions, if I don't use a hook, the trial toast only appears on the very first video of the day. Once used, the user is permanently stuck at 360p for all subsequent videos.

My ultimate goal was to use uBO to achieve three things for unlogged users: Automatically activate the trial, extend it indefinitely, and allow unlimited uses per day.

Here is how I was trying to piece that together:

1. Automatically activate the trial & select 1080p (Auto-clicker)

www.bilibili.com##+js(trusted-click-element, '.bpx-player-toast-wrap .bpx-player-toast-confirm-login, .bpx-player-control-wrap .bpx-player-ctrl-quality-menu-wrap .bpx-player-ctrl-quality-menu-item[data-value="80"]', !cookie:/^DedeUserID=/)

Purpose: The first selector clicks the toast to activate the trial mode, and the second selector clicks the menu to select the newly available 1080p quality. (As we discussed, trusted-click-element isn't designed for the repetitive SPA navigation required here).

2. Unlimited duration for trial mode (Bypass 30s limit)

www.bilibili.com##+js(nostif, trialTimer)

Purpose: Successfully stops the 30-second countdown, letting the 1080p stream play indefinitely.

3. Unlimited daily use of trial mode (Force the toast to appear on every video)
To get the "trial" toast to appear on every new video so it can be clicked again, I have to spoof Bilibili's daily usage state.

www.bilibili.com##+js(trusted-set, Object.prototype.expStore.isLoginTrialToastExpActive, true) // might break some features.
www.bilibili.com##+js(trusted-set, Object.prototype.isLoginTrialToastExpActive, true) // Does not work for this case.
www.bilibili.com##+js(trusted-set, Object.prototype.isViewToday, true) // Does not work for this case.

Purpose: Because Bilibili uses Object.defineProperty for things like isViewToday, set-constant / trusted-set fails to override the getter/setter. Because of this limitation in trusted-set, I had to fall back to a Userscript to hook Object.defineProperty and Object.defineProperties to modify the descriptor.

So, to answer your question: I am forcing the toasts to appear so that I can automatically click them to gain access to 1080p on every video without logging in.

I ended up having to use a Userscript for both the auto-clicking (due to the SPA limitation) and the property spoofing (due to the getter/setter limitation). This specific limitation with trusted-set bypassing getters/setters is what prompted my question about whether a set-desc / trusted-set-desc scriptlet would ever be considered in the future.

[gorhill]

I could add support for set-constant to set a value through Object.defineProperty with varag as, defined and as, getter.

As for trusted-click-element, I could add a directive such as loop to cause the scriptlet to restart from beginning.

[JoviDong]

I could add support for set-constant to set a value through Object.defineProperty with varag as, defined and as, getter.

As for trusted-click-element, I could add a directive such as loop to cause the scriptlet to restart from beginning.

That sounds like a fantastic approach! Adding a loop directive to trusted-click-element perfectly solves the SPA navigation problem and handles the repetitive auto-click sequence elegantly.

Regarding the set-constant addition:
If I understand this feature correctly, the usage would likely look something like:

example.com##+js(set, isViewToday, true, as, defined)
example.com##+js(set, isViewToday, true, as, getter)

This is highly suitable for simple cases where the property is strictly deterministic and there are no conflicts. However, based on various scenarios I have encountered while writing rules, it is often essential to perform conditional matching using the stringified representations of the owner object, property name, and descriptor (get/set/value). This ensures that the target of our modification is precise, thereby avoiding unintended errors caused by modifying the wrong target.

For instance:

• Same property scene: There are scenarios where owner objects belonging to different modules use the exact same property name but define different descriptor logic. For example, a tracker logger module defines a property enabled to control whether it should run, while a player danmaku plugin module also defines an enabled property. If I only want to disable the tracker logger, I would need conditional matching against the owner object's logic or the descriptor (get/set/value) logic to differentiate them.
• Prop name variants scene: There are scenarios where an owner object defines multiple sequentially named props, such as initAdPlugin, initAdPlugin1, initAdPlugin2, initAdPlugin3, etc. If I want to disable all of these ad plugins, I would need conditional matching on the property name using a regex like /initAdPlugin\d*/.

Because of these complex cases, I was wondering if a dedicated scriptlet might be more suitable to give rule writers fine-grained control over exactly which part of the descriptor is being replaced (via a dedicated target parameter). This leaves the standard uBO varargs (as, function, as, resolved, etc.) free to continue acting as type-wrappers for the constant, avoiding any conflict between where to place the constant and what type it should be.

Something along the lines of:

example.com##+js(set-desc, ownerMatch, propMatch, descMatch, target, constant)
example.com##+js(trusted-set-desc, ownerMatch, propMatch, descMatch, target, constant)

To give a concrete example, if we were to use this hypothetical set-desc to solve the Bilibili "Unlimited daily use of trial mode" issue (forcing the toast to appear on every video), the rule could target the getters for those specific properties like this:

www.bilibili.com##+js(set-desc, , isViewToday, isLoginTrialToastExpActive, get, true)

Here is how I envision the parameter usage:

/******************************************************************************/
/**
 * @scriptlet set-desc.js (or trusted-set-desc.js)
 * 
 * @description
 * Hooks `Object.defineProperty` and `Object.defineProperties` to override
 * property descriptors (value, getter, or setter) based on conditional matching.
 * 
 * If the scriptlet is injected without any arguments (e.g., `##+js(set-desc)`), 
 * it acts as a logger, outputting the intercepted owner object, property name, 
 * and descriptor details to the console to assist filter authors in inspecting 
 * targets and writing precise rules.
 * 
 * @param ownerMatch
 * A string or regular expression to match against the stringified owner object.
 * Leave empty to bypass matching the owner object.
 * 
 * @param propMatch
 * A string or regular expression to match the property name being defined.
 * Leave empty to match any property name.
 * 
 * @param descMatch
 * A string or regular expression to match against the stringified descriptor 
 * logic (get, set, or value). Leave empty to bypass matching the descriptor.
 * 
 * @param target
 * Specifies which part of the descriptor to modify explicitly. 
 * Accepted values: `get`, `set`, `gs` (for both get and set), or `value`. 
 * Leave empty to automatically infer and replace based on the existing keys 
 * in the intercepted descriptor (e.g., if `get` exists, replace `get`; if 
 * `value` exists, replace `value`).
 * 
 * @param constant
 * The constant value to apply to the intercepted descriptor target.
 * 
 * @param ...varargs
 * Optional parameters to wrap or cast the constant, matching uBO's existing 
 * style in `set-constant` (e.g., `as, function`, `as, callback`, `as, resolved`, 
 * `as, rejected`).
 * 
 * */

Of course, please note that set-desc is strictly just a hypothetical idea of mine to illustrate how we might handle conditional matching and precise descriptor targeting. I completely understand that it might be overly complex, out of scope, or that there might be a far better, simpler way to achieve this within uBO's existing architecture. I defer entirely to your expertise on the best approach!

Either way, the proposed loop, as, defined, and as, getter additions are incredibly helpful and much appreciated. Thank you again for considering this and for all your continuous work on uBO!

[JoviDong]

Btw, also other (declined) SPA-related threads:

• redirect: Feature Request: SPA-aware built-in redirect scriptlet for reliable YouTube Shorts redirection #3676

• removeparam: removeparam is sometimes not applied when clicking on links #1704 + duplicates:

  • Sometimes the $removeparam= parameter does not work #1767
  • ublockorigin cannot filter the tracking params in url in some particular case (filter function -> $removeparam) #1951
  • Netflix URL parameters not removed on click #2498

I encountered a similar issue with removeparam on Bilibili. I tried to strip the spm_id_from parameter, but it only worked on the first load. On SPA video switches, the hard-coded logic still appended it.

I eventually gave up on stripping it completely and adopted a compromise: using www.bilibili.com##+js(aeld, , 'spm_id_from='). While the hard-coded parameter remains during SPA navigations, this at least successfully blocks the JS-generated ones.