1760279 - Credentials can not be introduced at account.formula1.com with ETP set to STRICT

Status: VERIFIED FIXED

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

Description

[Raul Bucata]

Attachment: Screenshot_13.png

Environment:
Operating System: Windows 10 PRO x64
Firefox version:Firefox Nightly 100.0a1 (2022-03-17) (64-bit)

Preconditions:
ETP set to STRICT
Clean profile

Steps to reproduce:

1. Navigate to: https://account.formula1.com/#/en/login?lead_source=web_fantasy&redirect=https%3A%2F%2Ffantasy.formula1.com%2Fapp%2F%23%2F
2. Click on the "Email address" input field.
3. Observe the result.

Expected Behavior:
The text cursor is active and details can be introduced.

Actual Behavior:
Nothing happens.

Notes:

• Not reproducible with ETP set to STANDARD.
• Works as expected using Chrome.
• Screenshot attached.

Comment 1

[Thomas Wisniewski [:twisniewski]]

This is easier to reproduce in private browsing mode, as it's caused by their cookie-consent banner not going away properly. There is an invisible element overlaid on the rest of the content, div#consent_blackbar left behind, which can be manually hidden or goes away after 60 seconds. It's unclear why this is the case, but it seems logical it would be something that SmartBlock's shims aren't handling as the site's banner code expects.

Comment 2

[Thomas Wisniewski [:twisniewski]]

I took a second quick look at this one, and it appears that in Chrome, when the "Accept all cookies" button is clicked, the page seems to reload, and never bring up that #consent_blackbar element. But this reload doesn't happen in Firefox in strict mode, and the page doesn't even seem to try to clear the transparent overlay. The question is why this reload isn't happening.

Comment 3

[Thomas Wisniewski [:twisniewski]]

@Raul, this appears to be fixed for me now on the latest nightly builds of desktop Firefox. Could you confirm if it's working for you on such a build as well?

Comment 4

[Oana Arbuzov [:oanaarbuzov]]

Attachment: UnableToType.gif

The issue is still reproducible both in normal mode and private mode when accessing the page for the first time and after accepting cookies.

Note:

1. Reloading the page, typing becomes possible.
2. Clearing cookies and performing the steps again, the issue can be reproduced.

Tested with:
Browser / Version: Firefox Nightly 104.0a1 (2022-07-13)
Operating System: Windows 10 Pro

Comment 5

[Raul Bucata]

I get the same result. No fields can be activated, hyperlinks are not working and buttons are not responding. Reloading the page seems to fix the issue.

Tested with:

Browser / Version: Firefox Release 102.0.1 (64-bit)/ Firefox Nightly 104.0a1 (2022-07-14) (64-bit)
Operating System: Windows 10 PRO x64

Comment 6

[Thomas Wisniewski [:twisniewski]]

Ok, so I diagnosed this by using the console to add a beforeunload listener which called debugger, then clicked on Accept All to see the stack trace. Basically, once you click, their function updateGTM is called, which pushes a new command to the window dataLayer, {event: cookie_prefs_set}. Normally this ends up calling their custom tag in Publisher Tags, but our Google Analytics shim doesn't actually pass that event along, so the reload never happens.

Luckily we can just call the push method as expected if it exists, making sure to still run the eventCallbacks if not. That should cover our bases for why we override the datalayer's push command (asynchide causing page-load delays when GPT is blocked, etc).

Comment 7

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1760279 - have our Google Analytics/Tag Manager shim call the original dataLayer's push method if it has successfully loaded, so page's custom JS stored in GTM can run; r?ksenia

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d06c90a3129f
have our Google Analytics/Tag Manager shim call the original dataLayer's push method if it has successfully loaded, so page's custom JS stored in GTM can run; r=ksenia,webcompat-reviewers

Comment 9

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/d06c90a3129f

Comment 10

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

I managed to reproduce this issue on Firefox 103.0(build ID: 20220718155818) on Windows 10 64-bits. Verified as fixed on Firefox 104.0b7(build ID: 20220807190148) and Nightly 105.0a1(build ID: 20220807214336) on Windows 10 64-bits, Ubuntu 22.04, macOS 12.