1985773 - www.newser.com - Comments section not displayed with ETP Standard in PBM

Status: NEW

(Web Compatibility :: Privacy: Site Reports, defect, P2)

Description

[railioaie]

Environment:
Operating system: Windows 10
Firefox version: Firefox 142.0

Preconditions:
Clean profile
ETP Strict

Steps to reproduce:

1. Navigate to: https://www.newser.com/story/comments/374083/couple-charged-after-girl-11-gives-birth-at-home.html
2. Observe

Expected Behavior:
The comments section is displayed

Actual Behavior:
The comments section is not displayed

Notes:

• Reproduces with ETP Strict in Normal Mode and ETP Standard in Private Browsing mode
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/173755

Comment 1

[Manuel Bucher [:manuel]]

Unblocking newser.disqus.com (in addition to the shim?) unbreaks the comment section. Not sure why the smartblock doesn't show up.

Comment 2

[Manuel Bucher [:manuel]]

Can you take a look?

Comment 3

[Emma Zühlcke [:emz]]

I managed to get the placeholder once, but otherwise it just rendered a blank page.

There are two failures here:

1. The placeholder doesn't show
2. Even when unblocking Disqus via the protections panel the comment section does not load

As far as I can see for https://newser.disqus.com/embed.js neither the shim nor the real script loads properly. Since the shim script doesn't load we don't render a placeholder, even though the #disqus_thread element is present.
The website has a service worker. It might interfere with the load of both the placeholder script and the real script here. For the load of https://newser.disqus.com/embed.js in the devtools I see the error NS_ERROR_INTERCEPTION_FAILED. I also tried broadening the unblock url pattern to unblocksOnOptIn: ["*://*.disqus.com/*", "*://*.disquscdn.com/*"], allowing all subdomains of the CDN endpoint. Still fails with the interception error.

Allowing Disqus via the protections panel, then clearing site data and then reloading the page seems to show the Disqus section. I suspect clear site data will also remove the service worker and potentially bypass its caching logic.

Generally it's hard to debug this site because a lot of the code is heavily obfuscated.

Comment 4

[Emma Zühlcke [:emz]]

The issue might be that the fetch from the service worker is failing. I've built a demo that includes a service worker for caching, and if ETP is enabled the fetch fails. It fails even though Disqus is unblocked already. I wonder if our unblocking code could be broken for service worker fetch?

Demo page: https://playground.emz.im/embed-disqus-sw/
src: https://github.com/Trikolon/web-playground/tree/main/public/embed-disqus-sw

You can look at the exception via about:debugging, inspect the service worker, set a breakpoint in the catch block of the fetch and reload the site.

Comment 5

[Manuel Bucher [:manuel]]

Thanks for the demo page. Makes investigating a lot easier! Yeah, looks like our excemptions aren't honored for service worker. I can take a deeper look.

Comment 6

[Manuel Bucher [:manuel]]

Diagnosis:

• When deciding whether to unblock: channel.topLevelUrl throws

This returns NS_ERROR_FAILURE, due to browsingContext being nullptr (probably normal for service workers). Note that rv is NS_OK
https://searchfox.org/firefox-main/rev/8a50d94240fb8f312d8b061a425ff0755bcbaac4/netwerk/url-classifier/ChannelClassifierService.cpp#108

Pernosco sessions used to debug:

• ServiceWorkers don't seem to be excempted
• Non-ServiceWorker comparison

I can take a look soon on how to update UrlClassifierBlockedChannel::GetTopLevelUrl to also work for service worker channels soon.

Comment 7

[Manuel Bucher [:manuel]]

Note for tomorrow: Potentially using the topLevelPrincipal with the URI attribute could work.

Comment 8

[Manuel Bucher [:manuel]]

topLevelPrincipal is also nullptr in case of serviceWorker.

Comment 9

[Manuel Bucher [:manuel]]

Hm, that was once resolved in Bug 1437626 (Noticed that we already have tests when I tried to write some). Investigating why tests don't fail and whether additional testing is necessary or just fixing.

Tests added in https://phabricator.services.mozilla.com/D80185#change-2HUGQgrMoFt4

• test_classify_by_default.html
• trackerFrame.html

Patch that introduced the changes: https://phabricator.services.mozilla.com/D80182

Comment 10

[Manuel Bucher [:manuel]]

Another pernosco session with partial fix: https://pernos.co/debug/fiz92TpKFhc49UhMtHZ3ow/index.html

Comment 11

[Manuel Bucher [:manuel]]

More debugging in another pernosco session