Fixing Youtube infinite reload on Brave with uBO extension - #34162
Fixing Youtube infinite reload on Brave with uBO extension#34162griffinallen wants to merge 1 commit into
Conversation
This filter rule has an issue that surfaces when this rule is run in multiple environments simultaneously. For example, Brave Shields and uBO extension. The script has a mutation observer and when this observer fires, the video refreshes. This triggers the mutation observer in the other script, which causes a video refresh and triggers the mutation observer in the first script. This starts a video refresh loop. To avoid this loop, this change creates a shared variable between the two environments which indicates that the other script has triggered a video refresh. Once the other script starts running, if it sees that a video refresh is in progress, it aborts and breaks the loop.
|
We don't want to create a global variable so that YouTube can easily know that there's uBO installed just because there's another blocker interfering. Users should not use multiple blockers at the same time. |
|
That's understandable. Would you have any other suggestions for a fix to this? This is affecting a large number of Brave users and we are hoping to find a solution that works while Brave users are using the uBO extension, instead of forcing users to pick one tool. |
|
We always tell users to just use 1 blocker for years, regardless of which one users choose:
Making exceptions to one tool will just lead to endless requests of making exceptions to all other tools, and make us waste more time for issues that don't present with uBO alone. |
Brave can't be told apart from Chrome through the user agent string, so detection uses `navigator.brave` with `navigator.userAgentData.brands` as fallback. Both are synchronous, unlike `navigator.brave.isBrave()` -- the flavor must be settled before filter lists are compiled and cached. Brave still offers uBO in MV2, and a considerable number of Brave users run Brave Shields and uBO at the same time. Filters which are safe on their own can conflict when both blockers apply them, and list maintainers currently have no way to express that: uBlockOrigin/uAssets#34162
|
@gorhill can you consider |
Brave can't be told apart from Chrome through the user agent string, so detection uses `navigator.brave` with `navigator.userAgentData.brands` as fallback. Both are synchronous, unlike `navigator.brave.isBrave()` -- the flavor must be settled before filter lists are compiled and cached. Brave still offers uBO in MV2, and a considerable number of Brave users run Brave Shields and uBO at the same time. Filters which are safe on their own can conflict when both blockers apply them, and list maintainers currently have no way to express that: uBlockOrigin/uAssets#34162
Brave can't be told apart from Chrome through the user agent string, so detection uses `navigator.brave` with `navigator.userAgentData.brands` as fallback. Both are synchronous, unlike `navigator.brave.isBrave()` -- the flavor must be settled before filter lists are compiled and cached. Brave still offers uBO in MV2, and a considerable number of Brave users run Brave Shields and uBO at the same time. Filters which are safe on their own can conflict when both blockers apply them, and list maintainers currently have no way to express that: uBlockOrigin/uAssets#34162
Yep agreed.
This is a pretty disappointing stance. We are trying our best to support uBO in Brave, including going out of our way to offer it in brave://settings/extensions/v2 which means a lot of work both in the browser (with MV2-related patching) and on our backend (especially once Google removes uBO MV2 from Chrome Web Store in 10 days). This is a pretty bad bug: a uBO user on Brave basically can't watch YouTube videos. We want to support uBO on Brave, but we can't if uBO's stance is "don't use uBO with other ad & tracker blocking tools". |
If they use Brave Shields' content blocking function with uBO. Yes, multiple blockers interfering with each other happens all the time. That's the correct stance. We are volunteers here, not a company like Brave. We won't spend more of our little free time resources left to resolve every single conflict which don't appear with uBO alone. And vice versa, we don't go around and ask other tools to make them always compatible with uBO.
And what is your point here? Brave is also using uBO's filters for many complicated issues (which also take a lot of work and time of the volunteers to resolve too). This sounds like we are asking for favors and Brave receives nothing at the end? What kind of logic is this? Brave ignores the discussion of |
I never said anyone is asking for favors, where are you getting that from? Not sure why you had the worst-possible interpretation of my comment. Brave contributes heavily to the open-source adblocking ecosystem as well. We just want uBO to work for Brave users, full stop, and are happy to put in the time and energy to make that happen. |
|
You are the one who started about "mean a lot of work", not me, and I just stated the truth back. And you are the one who calls our stance "a disappointing stance", not me started talking anything about Brave. In which that stance is correct, and one of the stances we consistently tell users for years, to reserve our time and not burn out resolving conflicts with countless different blocking tools, which happen all the time for years. Again, we are volunteers here. You are free to do what you want on your sides. If the changes on our sides don't affect how websites see uBO and easy for us to understand, maintain and adjust, we can consider. I also said about both points from beginning: #34162 (comment) . If the proposed solutions don't fit us, we won't spend more time to resolve those conflicts. Again, we are volunteers here. |
Sounds good, thanks. |
No, uBO works fine on Brave. Did you miss that the issue occurs only if both uBO and Shields are enabled at the same time? We have been doing all the best to prevent running more than one blocker concurrently and really don't want to make any exception for this stance, and I personally hope Brave to be in line with us. I remember Brave's official X account validated running uBO on top of the Shield, which is quite against this: |
7 participants
URL(s) where the issue occurs
youtube.comDescribe the issue
This filter rule has an issue that surfaces when this rule is run in multiple environments simultaneously. For example, Brave Shields and uBO extension running on the same Brave browser instance. The script has a mutation observer and when this observer fires, the video refreshes. This triggers the mutation observer in the other script, which causes a video refresh and triggers the mutation observer in the first script. This starts a video refresh loop.
To avoid this loop, this change creates a shared variable between the two environments which indicates that the other script has triggered a video refresh. Once the other script starts running, if it sees that a video refresh is in progress, it aborts and breaks the loop.
Screenshot(s)
Versions
Notes
Typically, users have been told to "choose one" adblock tool because having more than one active tool can create issues like this. However, a considerable amount of Brave users have the uBO extension enabled. As a test, we added an exception rule for this filter on Brave and saw a 30% reduction in issues being reported for Youtube on Brave. When we removed our exception rule, we saw a 30% increase in issues being reported for Youtube on Brave.
If necessary, I can provide video or further testing. Please give suggestions if you have a better approach to this.