Class/id cosmetic selectors intermittently missed
See original GitHub issueCosmetic filtering uses a hidden_class_id_selectors routine to query for CSS to inject based on the classes of elements newly added to the page or modified, using an in-page MutationObserver. That applies to generic cosmetic rules that can be queried by a particular class or id selector that must appear in the page; i.e. rules of the form ##.class-selector
or ###id-selector
.
We’ve noticed a handful of instances where rules of this form fail to be applied to pages. @ryanbr has been manually adding workarounds for these rules, of the form e.g. ##div.class-selector
, which tricks Brave’s adblock engine into injecting these rules into all pages rather than finding them during MutationObserver queries. But this is not ideal, and we should discover and fix the root cause.
Issue Analytics
- State:
- Created a year ago
- Comments:6
Top GitHub Comments
Verification PASSED on
Used a clean profile on 1.45.127 and STR from https://github.com/brave/brave-core/pull/15930#issue-1447010515 to view the cookie consent banner on initial load of
https://websummit.com/
. Note, these steps reproduce intermittently, so you may not have any luck.Used a clean profile on 1.47.x and STR from https://github.com/brave/brave-core/pull/15930#issue-1447010515 and confirmed there was no cookie consent banner on initial load of
https://websummit.com/
. Refreshed (normal and hard refresh) several times, confirmed no cookie consent banner.Verified on
Samsung Galaxy S21
using the following build(s):Acceptance Criteria: https://github.com/brave/brave-browser/issues/26492#issuecomment-1301619849
Created a follow up issue regarding the cookie consent banner: https://github.com/brave/brave-browser/issues/27098