Skip to content
This repository has been archived by the owner on Oct 11, 2020. It is now read-only.

Ads are not blocked on bing.com web searches #30

Closed
ghost opened this issue Dec 11, 2016 · 8 comments
Closed

Ads are not blocked on bing.com web searches #30

ghost opened this issue Dec 11, 2016 · 8 comments

Comments

@ghost
Copy link

ghost commented Dec 11, 2016

Describe the issue

Bing ads do not get blocked, even when creating a filter for them.

One or more specific URLs where the issue occurs

https://www.bing.com/

Steps for anyone to reproduce the issue

  1. Make a web search on bing, for example: used cars

Your settings

It is reproduceable on the default settings

  • Browser/version: Microsoft Edge
  • uBlock Origin version: ublock edge
Your filter lists

Default filter lists

@gorhill
Copy link

gorhill commented Dec 11, 2016

If you add bing.com##.b_ad as custom filter, does it work?

@ghost
Copy link
Author

ghost commented Dec 11, 2016

Nope. Not on edge, specifically. On chrome, the ads are blocked. Also, other Adblocks don't get ads blocked on bing on edge. As well. There is even a bug report opened in Adblock Plus https://issues.adblockplus.org/ticket/4425

@gorhill
Copy link

gorhill commented Dec 11, 2016

I disabled the shadow DOM code path on Chrome (which is how ads are properly hidden on bing.com with Chrome), and I can reproduce the result of ads not being hidden (though sometimes they are). There is code in uBO's content script for yet another fallback when user styles and shadow DOM are not supported, but it does not always on bing.com because of a timing issue.

There is probably a way to fix this, I will experiment.

@nicole-ashley
Copy link
Owner

Thanks for jumping onboard @gorhill. When they do get through they seem to show up after a short delay, whereas with uBlock off they show instantly. So a timing issue sounds plausible.

As a quick test, I manually removed the inline display: block !important style from the ad element and it hid the element as expected. So the styles are being respected but only at a normal level of specificity.

@nicole-ashley
Copy link
Owner

This is resolved in 1.10.4, which will be available from the Store soon.

@gorhill
Copy link

gorhill commented Dec 19, 2016

@nikrolls The fix is not part of 1.10.4, as it needs more thorough testing before being released since how cosmetic filtering is enforced has been changed beyond trivial. Sorry for the confusion, I released 1.10.5b0 to make this clear.

Edit: never mind, I see you imported the fix.

@nicole-ashley
Copy link
Owner

Ah, ok -- no worries! I can re-jig the release to match yours (I'd rather keep it aligned). I'm preparing the Store release later today anyway, so no harm done.

Cursory testing shows that the fix appears to have resolved the issue in this ticket, so it's on the right track.

@gorhill
Copy link

gorhill commented Dec 19, 2016

Actually I thought it was nice to see the fix released for Edge, given that it still is preview mode, and that it does solve an issue which was not present on other platforms -- so the risk for Edge is really non-existent. I worry more about more testing needed for Chromium and Firefox. Maybe you could create a revision 1.10.4.1 specific to Edge to include that fix? (the extra ".1" would make it clear it's not exactly 1.10.4)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants