Environment:
Operating system: Windows 10
Firefox version: Firefox 128.0a1 (2024-05-16)

Steps to reproduce:

1. Access https://bitwarden.com/partners/become-a-partner/
2. Observe the form.

Expected Behavior:
The form is displayed.

Actual Behavior:
The form is not displayed.

Notes:

• Reproduces in ETP Strict Mode only
• Reproduces in Firefox Nightly
• Does not reproduce in Firefox Release, Chrome

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

Since the status is marked as affected for nightly and as unaffected for release, is it affected or unaffected for beta?
For more information, please visit BugBot documentation.

I was able to reproduce this in beta in ETP strict mode.

@Fred, could you take a look?

I can reproduce this on Mac Release and ended up with the following pushlog identifying bug 1880528.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5047e8bd22bcc67ef0ce958cd3206808fe5092e2&tochange=d2c8fe42db6d5c6dbf31d3ac381782d75d6ccb79

My full sequence of mozgression was.

$ ./mach mozregression --bad 125 --good 120` leads me to a pushlog with just the 124 merge from Nightly to Beta.
...
 7:12.03 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2af34b4c9adf8c8defd3251b569af9c38cc0a429&tochange=c8adbc03710a930647197b529273a320ac1391b9
 7:13.16 INFO: ************* Switching to autoland by process of elimination (no branch detected in commit message)
 7:14.10 ERROR: Unable to exploit the merge commit. Origin branch is mozilla-central, and the commit message for c8adbc03 was:
Update configs. IGNORE BROKEN CHANGESETS CLOSED TREE NO BUG a=release ba=release

$ ./mach mozregression --bad a8a8cdb0966b --good fcdb3e9046c6
...
 4:22.69 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5047e8bd22bcc67ef0ce958cd3206808fe5092e2&tochange=d2c8fe42db6d5c6dbf31d3ac381782d75d6ccb79

This is caused by the fact that Firefox blocks js.hsforms.net as analytics-trackers in ETP strcit mode.

Sorry I hadn't time to check. The regression ranges seem unexpected, I believe it's only introducing some preferences for the fetchpriority features which is disabled by default and was disabled on nightly at that time.

@Tim: do you mean it's unrelated to my fetchpriority patches? Or should I investigate?

@Tim, see question above in comment 6. And should we revert the js.hsforms.net blocking?

No, I don't think it's related. Blocking js.hsforms.net should be the cause here. And unfortunately, we cannot revert the js.hsforms.net blocking because we don't control the list. We use the Disconnect's list to block trackers in ETP strcit mode. Instead, people can use ETP toggle to disable ETP for the site to work in ETP strcit mode.

I just ran mozregression and got this regression range, agreeing with one of haik's from the middle of comment 4 around the Nightly merge -- with c8adbc03710a930647197b529273a320ac1391b9 being the first-bad commit -- but disagreeing with the one that he ended up finally landing on:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3a789882861bf458a92ed529bdbe4ddc39bd9671&tochange=c8adbc03710a930647197b529273a320ac1391b9

This is just the version number bump, which is an unusual thing to have regressions from. I'm pretty confident it's correct, though -- I double-checked with repeated --rev launches of mozregression, too.
This one is "good":

mozregression --launch 3a789882861bf458a92ed529bdbe4ddc39bd9671 -a  https://bitwarden.com/partners/become-a-partner/ -a "about:preferences"

This one is "bad":

mozregression --launch c8adbc03710a930647197b529273a320ac1391b9 -a  https://bitwarden.com/partners/become-a-partner/ -a "about:preferences"

(My STR with those^ runs is just to switch to "strict" in the preferences tab, and then reload the bitwarden tab.)

I guess our blocklist is somehow version-specific, and we've got different domains blocked for different versions based on the version-number? (in disconnect's dynamically-downloaded list, perhaps?)

(In reply to Tim Huang[:timhuang] from comment #8)

Blocking js.hsforms.net should be the cause here. And unfortunately, we cannot revert the js.hsforms.net blocking because we don't control the list. We use the Disconnect's list to block trackers in ETP strcit mode.

It's interesting that the blocking here is version-number-specific (based on my & Haik's mozregression runs) -- that's what makes this manifest as a regression. Is that a known/expected characteristic of how the Disconnect block-list integration works? (i.e. they offer different list based on what version Firefox says it has? Do we request the list using the Firefox version number as part of the request, somehow?)

Instead, people can use ETP toggle to disable ETP for the site to work in ETP strcit mode.

So based on that^, it sounds like you're suggesting this is effectively wontfix in terms of changes on our side, right? (I'm looking/asking because this is showing up on the weekly regression triage list at the moment, as a "carryover regression". I'm wondering what-if-any status we should adjust here, to reflect what-if-anything we might do to mitigate this, vs. if this isn't something we plan to mitigate & don't need to revisit weekly.)

(Also: it looks like maybe this might affect all cases of HubSpot embedded forms on 3rd-party sites, which I think is essentially what's happening/failing at this BitWarden site. Given that js.hsforms.net seems to be a newly-blocked thing, it might be worth keeping an eye out for other instances of this, in case we need to escalate/shim in some way...)

We provide version-specific lists, and hsforms.net was recently added. Bumping up the version number causes this website to breakage; it starts using a newer version of the list, which has this entry.

Theoretically, we can use a shim script to replace the script served by js.hsforms.net to fix this issue in ETP strict mode. However, the script is too complicated, and it's unlikely that we can create a shim for js.hsforms.net without significant effort. Other than the shim, we don't have another proper fix that can tackle this issue in the long term. So, I would say there is nothing we can do from our side for now.