Ublock: uBO 1.7.7beta -- Cosmetic filters using [style="..."] not working

[onestepbeyond]

Describing the issue

Since uBO 1.7.7_beta_, following sort of filter no longer works: forum.pcastuces.com##DIV[style="background-color:#eff4fc;margin:auto;font-size:1.2em;text-align:center;width:80%;border:1px solid #c9c9c9;padding:5px;"]

One or more specific URLs where the issue occurs

• https://forum.pcastuces.com/recuperer_fenetre_automatique_pour_telecharger_photos_iphone_5-f21s7118.htm?page=1&#5514204
• https://forum.pcastuces.com/est_ce_normal-f13s5020.htm?page=1&#5514250
• https://forum.pcastuces.com/zimbra-f6s69637.htm?page=1&#5514270
  

  Screenshot in which the issue can be seen

Steps for anyone to reproduce the issue

• With uBO 1.7.7_beta_, click any link above and notice that the _table_ near the footer is displayed.

• Reproduce with uBO 1.7.6 or prior and notice that this table is correctly hidden.

  My settings

• OS: Win XP SP3

• Browser/version: Firefox ESR 38.8.0
• uBlock Origin version: 1.7.7b8
  

  My filter lists

Your custom filters (if any): none

[gorhill]

Can you confirm this was with 1.7.7b8?

[onestepbeyond]

Yes, I do confirm. I think I noticed this since 1.7.7b7. (b9 impacted as well).
-- sorry, I had opened a duplicate topic in uAssets. I do not know which to close and which to leave open.

[gorhill]

Ok I see the issue, it's a code issue. The new code fixes cases like #963, but breaks cosmetic filters which use [style="..."]. This means cosmetic filters with such part will have to be apply in a declarative way only.

[onestepbeyond]

OK. What means exactly "declarative way" ? Should I manually change something in such filters ?
or this question makes no sense... ? I feel so stupid with uBO, how frustrating...

[gorhill]

Meanwhile, since you are using the beta version, use: forum.pcastuces.com##body > div:has(a[href="enregistrement.asp"])

[gorhill]

When I use "declarative" I mean the CSS rule will be injected in a style tag, and no further action will be taken. "Further action" means that uBO, on top of injecting style tags, will also visit all affected DOM elements to force display: none !important on them, to be sure sites do not try to override uBO's cosmetic filtering. But changing the style of an element to force-hide it has the side effect of modifiying its style attribute, which causes the DOM element to no longer match the cosmetic filter which is based on the style attribute. This is also what causes #435. The code refactoring in 1.7.7 made the issue more prominent (but resolved other cases) -- but it was already in there for FF at least since shadow DOM is not supported by default.

[onestepbeyond]

Meanwhile, since you are using the beta version, use: forum.pcastuces.com##body > div:has(a[href="enregistrement.asp"])

Wow! works and :has seems fantastic! :thumbsup:

Thanks for the additional explanations.

[onestepbeyond]

I just noticed that infortunately, the header goes away (same target).
Does not matter at this stage, I will wait for the release.

[gorhill]

Try forum.pcastuces.com##body > div[style]:has(:scope > a[href="enregistrement.asp"]).

[onestepbeyond]

As far as I can see after testing several scenarios, that filter seems working without side-effect.:ok_hand:

[gorhill]

Just for the fun of it I also came up with these:

forum.pcastuces.com##:xpath(/html/body/table//tr[@class="formsubtitle2"][.//text()="Publicité"])
forum.pcastuces.com##:xpath(/html/body/table//tr[@class="formsubtitle2"][.//text()="Publicité"]/following-sibling::tr[1])

[onestepbeyond]

WOW!  
J U S T  P E R F E C T !
If I had thought about that "impossibility" today, I would have said you read my mind! :sunny:

[onestepbeyond]

What do you think about adding this third filter:
forum.pcastuces.com##:xpath(/html/body/table//tr[@class="formsubtitle2"][.//text()="Publicité"]/following-sibling::tr[2])
(I just changed the final "1" to "2")
... to reproduce the standard height existing between the other posts on the page.

I tried out and do not feel that this generates some quirk, unless I am mistaken.

Edit: Long page is better: https://forum.pcastuces.com/installer_korora_sur_une_vm_et_sur_disque_dur_a_cote_de_linuxmint__-f8s15194.htm

[gorhill]

Looks fine to me, I hadn't noticed there was an empty row used for spacing.

[onestepbeyond]

Aaargh! it brokes pagination (in the bottom of the page, above the footer).

No matter, I let only 1 sibling, that's fine. Le mieux est l'ennemi du bien.
Thank you again you for your help, much appreciated.

[gorhill]

Ça va aider quand je vais implémenter #1772.

[gorhill]

Wish I had found this before: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/hidden. This completely solves the issue.

[onestepbeyond]

This completely solves the issue.

I'm infortunately not technically advanced enough to understand all the implications of this good news, and the _language barrier_ is another obstacle.
However, I sometimes use the display: none !important; declaration in the userContent.css file to hide some elements.
So, dumb question, sorry, am I supposed to make something on my side to solve the issue?

[gorhill]

I am not asking you to understand anything, it's a code repo and I will often add dev notes to issues.

[phrokton]

@gorhill How are you generating XPath?

For firefox I once used

https://addons.mozilla.org/en-US/firefox/addon/xpather/

https://addons.mozilla.org/en-US/firefox/addon/yarip

[gorhill]

How are you generating XPath?

I just craft it manually according my observations of the DOM (in doubt, I consult this cheatsheet). There is also a _Copy XPath_ menu entry in Chromium's inspector (can't see this in Firefox though).

[gorhill]

Reported issue was fixed with 02e6b088ef0716a087986e093331ad4a5a1d5b67.