Uassets: Bing.com

[DandelionSprout]

URL(s) where the issue occurs

https://www.bing.com/search?q=nrk

(In the event that the ads are too regionalised to be triggered when searching for a Norwegian media group, there's many other example URLs in https://github.com/uBlockOrigin/uAssets/issues/5724#issuecomment-497969628 that can be tried out.)

Describe the issue

Ad listings on the top and bottom of Bing results for most (but not all) search terms, which are currently not blocked by any notable adblock list that I'm aware of.

Screenshot(s)

Versions

• Browser/version: Vivaldi 2.5.1525.46 64-bit for Windows
• uBlock Origin version: 1.19.6

Settings

During testing, the only lists I had turned on were EasyList and the main uBlock Filters list.

Notes

My personally recommended fix: bing.com###b_results > li:has(.b_aslcpy)

I was made aware of this in https://github.com/DandelionSprout/adfilt/issues/36, and I was quickly able to confirm the presence of the reported problem. As Bing is an international multi-language website, I'm reporting this to you guys, first and foremost (as well as to EasyList).

[dumbusernameidk]

I can't reproduce with default setup on Chrome or FF.

[DandelionSprout]

I for one am consistently able to reproduce it in Chrome, FF, and Vivaldi, be it with or without being logged in.

[DandelionSprout]

Presuming that there's regional variations in search results between countries, here's some other search terms where I've been able to trigger ads, in case it makes it easier for people from other countries to replicate the ads:

• https://www.bing.com/search?q=nintendo+switch
• https://www.bing.com/search?q=wheat
• https://www.bing.com/search?q=sony
• https://www.bing.com/search?q=fortnite
• https://www.bing.com/search?q=lalaloopsy
• https://www.bing.com/search?q=nella+the+princess+knight

[DandelionSprout]

Closing this issue report for now, as EasyList will be adding an entry for these ads to their list the next time they sync their sublists, which shouldn't be long to wait for at all: https://github.com/easylist/easylist/pull/3559

[DandelionSprout]

Re-opening, after I realised that smed79's pull request hadn't been merged yet, and that it could very well take days before the fix is actually added to EasyList.

[smed79]

@ryanbr @khrin fyi.

[dumbusernameidk]

I still can't reproduce even with UBO off. Probably based on region or something i'm not getting anything on US.

[mapx-]

reproducible in firefox (and not in chrome for me)

[ryanbr]

Does this help / cause any issues?

bing.com###b_results > li > ul > li > div > .b_caption

[DandelionSprout]

For the purposes of EasyList, bing.com###b_results > li > ul > li > div > .b_caption does technically remove the ad results, but leaves some text remnants from ad subresults behind (if the page originally had any ad subresults):

[DandelionSprout]

For certainty's sake, I've also tested all this after turning off AdGuard for Windows Beta entirely (after I discovered that it had a completely new and confusing browser coverage setting that may or may not have been targeting my main browsers), and by removing NoCoin entries from my OS' hosts file.

[ryanbr]

bing.com###b_results > li > ul > li > div > .b_caption
bing.com###b_results > li > ul > li > div > .b_vlist2col

[DandelionSprout]

Seems to work pretty well for me. In fact it seems to work more consistently than mapx-'s fix as well.

I hereby vote in favour of those two entries being added to EasyList.

[mapx-]

it seems to work more consistently than mapx-'s fix

what do you mean ?

[DandelionSprout]

At the current point in time, I can't seem to get your Xpath entry to be noticed by my highly-tampered-with Chrome setup, only by my minimalistic Vivaldi and Firefox test setups.

[mapx-]

yeah, still just a story. Provide real details.

[DandelionSprout]

I am unsure what the criteria is for 'real details', but I'll try.

So far I can tell that the recognition problem also extends to the element picker.

Vivaldi (works):

Chrome (while temporarily reverted to Nano stock settings and with several extensions like I don't care about cookies, Nano Defender, and Tampermonkey turned off):

[mapx-]

sure, you have to replace Ad with Annonse

[DandelionSprout]

...aaaaaaaaah. Well spotted. My fault (sort of). 😅

If so, then I suppose it'd be preferential to find a language-neutral solution, and Fanboy's solution seems to me personally to work as intended for that.

[mapx-]

yeah, but I'm sure bing will evolve to some yandex or FB approach.

[ryanbr]

i prefer a more generic approach imo, covers both extensions

[mapx-]

@DandelionSprout could you test this filter
bing.com##[onclick^="ad_choice"]:nth-ancestor(2)

[DandelionSprout]

@mapx- It technically works, but leaves ad subresults remaining in much the same way as https://github.com/uBlockOrigin/uAssets/issues/5724#issuecomment-498015173 originally did.

bing.com##[onclick^="ad_choice"]:nth-ancestor(3) (replacing the '2' with a '3') seems to remove the ad results entirely.

Compare

with

[kathampy]

I have the same issue in Edge (Chromium) but not in Firefox.

[reallyuniquename]

I get such ads on Firefox. Basically it's an additional li with random classname that sits above li.b_ad (which is blocked by Easylist). The one in the bottom has also b_adBottom class. I suppose it could be a regional thing although my Bing's language is set to English.

Anyway I'm using these:

www.bing.com###b_results > li:first-child:not(.b_algo)
www.bing.com###b_results > li.b_adBottom