lightnovelpub.com: ads

[Tarzan9348]

Prerequisites

• I read and understand the policy about what is a valid filter issue.
• I verified that this issue is not a duplicate. (Use this button to find out.)
• I forced an update of my filter lists. (Click the "Purge all caches" button while holding the 'Shift' key, then click the "Update now" button.)
• I did not remove any of the default filter lists, or I have verified that the issue was not caused by removing any of the default lists.
• I did not enable external filter lists, or I have verified that the issue still occurs without enabling external filter lists.
• I do not have custom filters/rules, or I have verified that the issue still occurs without custom filters/rules.
• I am not using uBlock Origin (uBO) along with other content blocker extensions.
• I have verified that the web browser's built-in blocker or DNS blocking (standalone or through a VPN) is not causing the issue.
• I did not answer truthfully to ALL the above checkpoints.

URL address of the web page

https://www.lightnovelpub.com/

Category

ads/anti-adblock

Description

When adblock is enabled it shows what is seen in the attached picture. I've found one of the elements: div.hdmGTxag_.hdmGTxag:nth-of-type(1) and the number at the end is usually 1-10 whereas the random letters "hdmGTxag_.hdmGTxag" change every 24~ hours so even if you add them to the filter list it will appear again the next day,

Screenshot(s)

Screenshot(s)

Configuration

uBlock Origin: 1.47.4
Chromium: 111
filterset (summary): 
  network: 86449
  cosmetic: 39087
  scriptlet: 17051
  html: 0
listset (total-discarded, last-updated): 
  default: 
    user-filters: 0-0, never
    easylist: 64204-44, 2d.12h.23m
    easyprivacy: 31059-1174, 2d.12h.22m
    plowe-0: 3757-931, 6d.12h.52m
    ublock-abuse: 78-0, 6d.12h.50m
    ublock-badware: 4736-114, 2d.12h.21m
    ublock-filters: 32020-83, 2d.12h.20m
    ublock-privacy: 291-1, 6d.12h.45m
    ublock-quick-fixes: 387-33, 23h.49m
    ublock-unbreak: 1932-40, 2d.12h.19m
    urlhaus-1: 6712-0, 23h.48m
filterset (user): [empty]
modifiedUserSettings: [none]
modifiedHiddenSettings: [none]
supportStats: 
  allReadyAfter: 31020 ms (selfie)
  maxAssetCacheWait: 118 ms
popupPanel: 
  blocked: 5
  blockedDetails: 
    connatix.com: 1
    google.com: 1
    googlesyndication.com: 1
    googletagmanager.com: 1
    translate.googleapis.com: 1

[gorhill]

I don't see anti-blocker message, but I do see placeholders. Does this work?

lightnovelpub.com##.ofh

[mapx-]

same here, only leftovers

lightnovelpub.com##*:matches-css-before(content:/Adv/)
lightnovelpub.com##.cnx_container

[gorhill]

@mapx- I think the following is better:

##.adsbygoogle:upward(1)

*:matches-css-before(content:/Adv/) would require to visit all elements on the page and call an expensive matches-css for each of them.

[Tarzan9348]

same here, only leftovers

lightnovelpub.com##*:matches-css-before(content:/Adv/)
lightnovelpub.com##.cnx_container

this worked perfectly

[garry-ut99]

this worked perfectly

Not perfectly, even lightnovelpub.*##.adsbygoogle:upward(1) still causes ad placeholders appearing / blinking for a fraction of second before they are hidden.

After disabling already existing filters:

lightnovelpub.*#@#.adsbygoogle:upward(1)
lightnovelpub.*,webnovelpub.com#@#div[class] > ins.adsbygoogle:upward(div[class])

and adding this one instead: lightnovelpub.*##div:has(>.adsbygoogle)
there is no blinking anymore, and the ad placeholders are hidden instantly in Chromium (Opera)
(in Firefox they're still blinking).

[gorhill]

There are 200+ div on that page, so I rather we keep ##.adsbygoogle:upward(1). Once Firefox natively supports :has(), we can start preferring it to procedural filters. (and I don't see the blinking on my side with :upward()).

[MasterKia]

What does ##.adsbygoogle:upward(1) actually hide?
On my side they're already hidden by existing filters. Only needing ##.cnx_container.

https://www.lightnovelpub.com/novel/lord-of-the-mysteries-wn-14032207

[gorhill]

hidden by existing filters

Yes, the ones @mapx- added 4 hours ago.

[MasterKia]

No, I mean these existing filters:
2fe9517#diff-3790c913c3f827c1361caec59a0720befebcc3c0a4a7092ef1638e244fd54e33R1038-R1044

[gorhill]

I could reproduce the placeholders, and ##.cnx_container was not enough, see https://www.lightnovelpub.com/hub_08032132. Anyway, as far as I am concerned, case closed, I'm out.

[garry-ut99]

Once Firefox natively supports :has(), we can start preferring it to procedural filters.
(and I don't see the blinking on my side with :upward()).

Or to use !#if env_ directives until then, but only if several users confirm page's elements blinking in a given site.

---

What does ##.adsbygoogle:upward(1) actually hide? On my side they're already hidden by existing filters. Only needing ##.cnx_container.

Yes, even before I wrote my comment I already noticed the same strange thing like you:
I could reproduce ad placeholders before 2fe9517 landed,
but after I updated my filters I get no ad placeholders anymore even with the upward() filter whitelisted, because the old filter: lightnovelpub.*,webnovelpub.com##div[class] > ins.adsbygoogle:upward(div[class]) hides them already.
The question is why the old filter wasn't hiding them before 2fe9517 landed.

[MasterKia]

@garry-ut99 It's the second time I have seen this "strange" behavior that you described. The first time was a few days ago, and after I force updated my filterlists the placeholders got hidden even though the "working filters" had already been downloaded before.

It would be interesting if others could reproduce it too (by adding #@#.adsbygoogle:upward(1) + force updating the filterlists).