There is an ad on https://www.reuters.com/

[SergeyZhukovsky]

Description

There is an ad on top when you visit https://www.reuters.com/ . It started to appear in 1.21.x.

Steps to Reproduce

1. Visit https://www.reuters.com/

Actual result:

Observe an ad on top

Expected result:

There is no ad

Reproduces how often:

Always

Brave version (brave://version info)

Version/Channel Information:

• Can you reproduce this issue with the current release? Yes, starting from 1.21.x
• Can you reproduce this issue with the beta channel?
• Can you reproduce this issue with the nightly channel?

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields?
• Does the issue resolve itself when disabling Brave Rewards?
• Is the issue reproducible on the latest version of Chrome?

Miscellaneous Information:

[kjozwiak]

@SergeyZhukovsky we're going to include this one in 1.21.x - Release #2 which will also have the revert for #14471. Should we add the OS/Android label? Assuming this also affected Android? Even with #14471 reverted, we can still take a look at the above case and at least make sure that it was fixed with the revert.

[kjozwiak]

@brave/legacy_qa spoke with @SergeyZhukovsky. We'll need to do the following for this issue:

• verify that the above doesn't occur anymore once we revert the cosmetic filtering changes from desktop via Brave shields are not working properly #14471
• check and ensure that the above case doesn't happen on Android when viewing pages in Desktop mode rather than mobile.

[kjozwiak]

Verification PASSED on Samsung Galaxy Tablet A running Android 10 using the following build:

1.21.74 CR: 89.0.4389.72

1.21.73 CR: 89.0.4389.72	1.21.74 CR: 89.0.4389.72

---

Verification PASSED on Samsung S10+ running Android 11 using the following build:

1.21.74 CR: 89.0.4389.72

1.21.73 CR: 89.0.4389.72	1.21.74 CR: 89.0.4389.72

---

Verified passed with

Brave	1.21.74 Chromium: 89.0.4389.72 (Official Build) (64-bit)
Revision	3f345f156bfd157bd1bea06310e55f3fb2490359-refs/branch-heads/4389@{#1393}
OS	Linux

1.21.73 CR: 89.0.4389.72	1.21.74 CR: 89.0.4389.72

---

Verified PASSED using

Brave	1.21.74 Chromium: 89.0.4389.72 (Official Build) (x86_64)
Revision	3f345f156bfd157bd1bea06310e55f3fb2490359-refs/branch-heads/4389@{#1393}
OS	macOS Version 11.2.2 (Build 20D80)

No ad seen on reuters.com.

---

Verification PASSED on Win 10 x64 using the following build:

Brave | 1.21.74 Chromium: 89.0.4389.72 (Official Build) (64-bit)
-- | --
Revision | 3f345f156bfd157bd1bea06310e55f3fb2490359-refs/branch-heads/4389@{#1393}
OS | Windows 10 OS Version 2009 (Build 19042.844)

1.21.73 CR: 89.0.4389.72	1.21.74 CR: 89.0.4389.72

[kjozwiak]

Looks the issue still happens after you refresh the page multiple times. Quickly talked to @SergeyZhukovsky and this appears t be the same issue that the Skip Ads issue TY is experiencing. Seems like some type of race condition where the script either loads to early or to late and the ad gets through. Exampe:

• 1.21.74 CR: 89.0.4389.72 - Reproduced
• 1.21.73 CR: 89.0.4389.72 - Reproduced
• 1.20.108 CR: 88.0.4324.182 - Reproduced

I'll file an issue re: the cosmetic filtering race conditions that Brave seems to experience. However, 1.21.74 CR: 89.0.4389.72 is a lot better as it was basically 100% reproducible via 1.21.73 CR: 89.0.4389.72 due to a parsing regression.

[ryanbr]

I got a whitespace issue in Beta/Nightly @SergeyZhukovsky (unfortantly my Brave nightly was having issues with extensions, so just tested in Chrome). From my screenshot below ##+js(acis,..) was called/inited a few times (6) on the home page. Is our code doing the same?