1771557 - Sports Illustrated articles have a gray bar across them (covering up article content), if strict tracking protection is enabled (outside of Europe)

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Start with fresh Firefox profile (optional but recommended; I'm using a fresh profile)
2. Set Tracking Protection to 'strict' at about:preferences#privacy
3. Visit https://www.si.com/sports-illustrated/2022/05/24/pickleball-fastest-growing-sport-daily-cover
4. Scroll down (e.g. hit page-down 5-6 times)

ACTUAL RESULTS:
There's a floating gray bar, fixed in place on the screen, which is initially just before the article's title, but it stays in place as I scroll and covers up article content.

EXPECTED RESULTS:
Gray bar should disappear after I scroll down (this is what happens when I have default tracking protection settings; specifically, an ad loads, and then the gray bar stops floating over the content and snaps to the top of the page).

Not sure what or how much we can do here; this is presumably some ad/tracking script that loads an ad and then dynamically modifies the layout/positioning of this component to stop it from floating, and it doesn't get a chance to modify the layout if we block the script. Or something like that.

(Ideally this might be something that we could "shim", though.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the bug (actual results) in strict mode, and then the site working as-expected in standard mode

Comment 2

[Daniel Holbert [:dholbert]]

The screencast shows the issue from ~t=5s to 16s (where I'm scrolling around the article, with strict ETP mode enabled).

Then I switch to standard mode and reload the article (around t=23s) and the issue briefly reproduces and then an ad loads in the gray bar (around t=28s) and then the gray bar disappears (around t=30s) (relocating to the top of the page) as noted in comment 0; and from that point on the article is nicely readable, not covered up.

Comment 3

[Thomas Wisniewski [:twisniewski]]

After hunting around for a while, it seems as though the problem is that a script is being blocked which is telling the Google publisher tags system to refresh ad slots, https://pub.doubleverify.com/signals/pub.js.

This may be shimmable. I'll investigate further.

Comment 4

[Thomas Wisniewski [:twisniewski]]

Yes, it's possible to shim this one and fix this breakage, so I'll add it my queue of shim fixes I'm hoping to release soon.

Comment 5

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1771557 - add a SmartBlock shim for DoubleVerify; r?ksenia

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4fa5578029c9
add a SmartBlock shim for DoubleVerify; r=ksenia,webcompat-reviewers

Comment 7

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/4fa5578029c9

Comment 8

[Alin Ilea, Desktop QA]

Attachment: 2022-07-06_14h49_32.mp4

Hi, I can still reproduce the issue in Beta 103.0b4 and the latest Nightly 104.0a1 (2022-07-05) using Windows 10. Is there something that I missed there?
Thanks.

Comment 9

[Thomas Wisniewski [:twisniewski]]

Interesting, Alin. I'm not seeing the bar covering up any content on my MacBook after scrolling around on the provided URL.

If you open the developer tools web console on that tab, do you see a warning (usually in yellow and probably near the top of the scrollable log) which says "DoubleVerify is being shimmed by Firefox"? If not, do you at least see "DoubleVerify" in the list of SmartBlock shims in about:compat?

It's plausible that in different regions, they rely on different tracking scripts.

Comment 10

[Alin Ilea, Desktop QA]

Attachment: 2022-07-07_10h05_33.png

Indeed, I see both of them, the DoubleVerify is being shimmed by Firefox warning in console and DoubleVerify in about:compat as well.

Comment 11

[Thomas Wisniewski [:twisniewski]]

Thanks! Unfortunately that means we'll need someone who can reproduce the issue to diagnose it further, since I can't currently see the problem. Out of interest, do you see any errors or interesting messages about ads or blocked resources in the full console log? (It seems rather large). I usually compare with ETP enabled, and then disabled, to find out which messages in the log seem to be related to ETP. If you have the time to help do that, it would be appreciated!

Comment 12

[Alin Ilea, Desktop QA]

Attachment: console errors.png

Sure thing. Here are all the errors displayed in console, with Strict mode enabled. Using Standard mode, there are no such errors, only 2-3 GET errors. Just let me know if I can help with anything else.

Comment 13

[Alin Ilea, Desktop QA]

Attachment: console warnings.png

And here are all the warnings displayed.

Comment 14

[Daniel Holbert [:dholbert]]

FWIW the issue doesn't repro anymore for me using STR in comment 0 (as long as I have DoubleVerify enabled at about:compat).

However: if I use Mozilla VPN and choose Romania|Bucharest or France|Paris as my exit location (maybe anywhere in Europe?), then I can reproduce the issue again. I also notice there's a more-aggressive allow-cookies overlay at pageload, too (which I click "Accept" on); so it's possible there's some sort of race condition that plays out differently with that overlay...?

Thomas, any chance you have VPN software that could let you spoof a European location? If so, I suspect you'll be able to reproduce the remaining piece of this.

Comment 15

[Thomas Wisniewski [:twisniewski]]

Yes, it seems as though some other blocked scripts are still causing another bar to remain on-screen after dismsising their cookie consent banner (which can be done via VPN connection through Europe). I'll try to find time to figure this one out, but it's not looking like a trivial diagnosis.

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Thomas Wisniewski [:twisniewski] from comment #15)

I'll try to find time to figure this one out, but it's not looking like a trivial diagnosis.

Given this is a distinct issue and probably not landing right away, maybe it'd be best to spin that off to a "for-users-in-Europe" followup bug?

(and rename this bug to add "...for users who receive the USA version of the website" in the title, or something like that, and then we can close this as fixed again and investigate the remaining issue on the followup?)

Comment 17

[Thomas Wisniewski [:twisniewski]]

Sure, why not. I've filed bug 1779504 as a Eurozone variant of this bug.