Ublock: chromium browser - ublock bug

Created on 4 Nov 2017  ·  3Comments  ·  Source: gorhill/uBlock

Most helpful comment

For case 1, the site is removing uBO's injected CSS rules. This is unfortunately a Chrome issue, it does not support user styles. uBO tries its best to deal with this by adding display: none !important as inline style, but it does so only if it sees it's needed when it detects an element's inline style was tampered with -- the usual way sites would work around blockers is to add inline style display: block !important (demo). This site just removes uBO's style, and this does not trigger uBO's tampering detection code.

This does not happen with uBO dev build because I changed the way I insert the CSS rules, but it's just a matter of time before the site figure this and add code to deal with the new code. With such cases, I just advise people to use Firefox, it supports user styles and sites cannot remove uBO's injected styles. There is also quite less of an overhead with Firefox in dealing with cosmetic filtering as uBO does not have to constantly keep an eye on the visibility of elements it's supposed to hide -- something it has to do with Chrome, and with no guarantee of results as seen here

For case 2, I can reproduce, this is a regression as a result of all the changes.

All 3 comments

Closing and marking as _invalid_, as per CONTRIBUTING.

Using UBO 1.14.12 on Chromium 62.0.3202.75

  • UBO default setting without regional filters
  • add dobreprogramy.pl##.gamescarousel to My filters
  • go to https://www.dobreprogramy.pl/
  • this element is not blocked:

image

Works fine in UBO dev 1.14.17.100, but:

  • add this filter ###cookiesPanel:not(body):not(html)
  • cookie message on top of page is not blocked
  • works again if :not(body):not(html) part is removed from filter

image

For case 1, the site is removing uBO's injected CSS rules. This is unfortunately a Chrome issue, it does not support user styles. uBO tries its best to deal with this by adding display: none !important as inline style, but it does so only if it sees it's needed when it detects an element's inline style was tampered with -- the usual way sites would work around blockers is to add inline style display: block !important (demo). This site just removes uBO's style, and this does not trigger uBO's tampering detection code.

This does not happen with uBO dev build because I changed the way I insert the CSS rules, but it's just a matter of time before the site figure this and add code to deal with the new code. With such cases, I just advise people to use Firefox, it supports user styles and sites cannot remove uBO's injected styles. There is also quite less of an overhead with Firefox in dealing with cosmetic filtering as uBO does not have to constantly keep an eye on the visibility of elements it's supposed to hide -- something it has to do with Chrome, and with no guarantee of results as seen here

For case 2, I can reproduce, this is a regression as a result of all the changes.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

FuglyLookingGuy picture FuglyLookingGuy  ·  3Comments

Phlipout picture Phlipout  ·  3Comments

ghost picture ghost  ·  3Comments

GSNord picture GSNord  ·  3Comments

UnicornVariant picture UnicornVariant  ·  3Comments