The ‘’Reject Requests’’ button displays incorrect telemetry after focusing outside of the browser for a few seconds
Categories
(Firefox :: Messaging System, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox110 | --- | unaffected |
firefox111 | --- | affected |
firefox112 | --- | affected |
People
(Reporter: ctataru, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
8.69 MB,
video/quicktime
|
Details |
[Affected versions]:
- Firefox Beta 111.0b6, Build ID 20230226190100
- Firefox Nightly 112.0a1, Build ID 20230227092207
[Affected Platforms]:
- MacOS 12.4
- Windows 10x64
[Notes]:
- If the ‘’Reject Requests’’ button is pressed immediately after the banner is displayed the button will work as expected.
[Prerequisites]:
- Have the Cookie Banner UI enabled.
- Have the browser.ping-centre.log pref set to true.
- Have the Browser Console opened.
[Steps to reproduce]:
- Start the browser with the profile from prerequisites and navigate to a website with cookie banner (eg. cnn.com).
- The Cookie Banner Reduction onboarding doorhanger is displayed below the Protection Panel.
- Focus outside of the browser and wait a few seconds.
- Click the ‘’Reject Requests’’ button.
- Observe the Browser Console.
[Expected results]:
- An ENABLED event is displayed:
TELEMETRY PING (activity-stream): {"experiments":{"task-continuity-sync-after-tab-change-rollout-40":{"branch":"sync-after-tab"}},"locale":"en-US","version":"111.0","release_channel":"beta","source":"CFR","message_id":"CFR_COOKIEBANNER","bucket_id":"CFR_COOKIEBANNER","event":"ENABLE","addon_version":"20230226190100","client_id":"a663b457-d412-4c6d-96c4-bcfe7faed732"}
[Actual results]:
- An ‘’PopupNotifications._onButtonEvent: Button click happened before the security delay: 79.31674999999814ms’’ is displayed in the Browser Console.
[Additional Notes]:
- At a second click on the ‘’Reject Requests’’ button the correct Telemetry ping is displayed and the doorhanger is dismissed.
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Comment 1•2 years ago
|
||
NI @jhirsch @dwalker to help prioritize and triage the issue Thanks
Comment 2•2 years ago
|
||
Thanks for filing this, :ctataru.
I'm not sure, but I suspect the underlying issue here has to do with how the browser handles clicks when the application does not have app focus. I wonder if this same issue can be reproduced with other doorhangers / other uses of the notification panel.
In terms of prioritization, since users should only ever click the "enable" button in the doorhanger once, and then they will never see the doorhanger again, I don't think this is a big deal. I'll mention this bug to Data Science, and ask them to help us coalesce multiple 'accept' clicks from individual client_ids in our dashboards. This doesn't seem serious enough to attempt a fix this late in the cycle, since we have a workaround on the server side.
Comment 3•2 years ago
|
||
Actually, now I'm curious. :ctataru, can you check if the reject button has the same behavior?
Comment 4•2 years ago
|
||
To expand on this, it appears that this error is a security feature built in to dialogs in Firefox in an attempt to thwart certain kinds of timing attacks: https://searchfox.org/mozilla-central/source/toolkit/modules/PopupNotifications.sys.mjs#1890
For the curious, this blog post elaborates on the threat model.
The real bug here is likely that the messaging system UI should show the buttons as disabled during this security delay, to eliminate possible confusion/frustration on behalf of the user. Other than that this appears to be working as intended.
Reporter | ||
Comment 5•2 years ago
|
||
Hello,
I have tested this scenario with the ‘’Not now’’ button, using the latest Firefox Nightly 112.0a1 (Build ID: 20230228085339) and the latest Firefox Beta 111.0b6 (Build ID: 20230226190100) and it appears that after defocusing the browser for a few seconds and then pressing the ‘’Not now’’ button, a security delay it’s registered in the browser console.
Updated•2 years ago
|
Updated•2 years ago
|
Description
•