1949176 - Blocked dialog displayed when pasting from clipboard after canceling the DLP scan in gsheets

Status: NEW

(Firefox :: Data Loss Prevention, defect, P4)

Description

[Bianca Hidecuti, Desktop Test Engineering [:bhidecuti]]

Attachment: video showing the issue

Found in

• 137.0a1 (2025-02-19)

Affected versions

• 137.0a1

Preconditions

• Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view
• Create a distribution folder inside the Firefox folder and paste the policies-1.json to it and then rename it to policies.json
• Run the DLP agent in CMD using: .\content_analysis_sdk_agent.exe --user --toblock=.\d{3}-?\d{2}-?\d{4}. --towarn=.warn. --delays=10

Tested platforms

• Affected platforms: Windows 10/11
• Unaffected platforms: Ubuntu, macOS

Steps to reproduce

1. Go to https://drive.google.com/drive/home and open a Google Sheet
2. Copy any random text and paste it inside the gsheet using ctrl+V (only click once on the desired cell)
3. Press the “Cancel” button from the “Scan in progress” dialog and observe the behavior

Expected result

• The scan is canceled and no other dialogs are displayed

Actual result

• “You’re not permitted to paste this content” dialog is displayed

Regression range

• Mozregression points to bug 1936020

Additional notes

• See the attached video
• Not reproducing on other pages (including on other gdocs) or if double-clicking on the cell before pasting
• The content is allowed in cmd

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:gstoll, since you are the author of the regressor, bug 1936020, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[David Parks [:handyman]]

This is hitting the content analysis cache when the page makes additional requests after the WARN response is turned into a BLOCK response by the user. Note that these additional requests are therefore in a separate User Action. We added showing the BLOCK dialog when the cache responds with BLOCK in bug 1936020 to avoid silently blocking things that the user tries to do. These are about additional requests that the page makes on its own -- we can't easily know if the user initiated a specific request but maybe we could show the BLOCK dialog for a cache hit only if some amount of time (like a second) has passed since the last one was shown.

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

[Tracking Requested - why for this release]: Regression in google docs with a duplicate report, seems potentially like a bad regression.

Comment 5

[Pascal Chevrel:pascalc]

Tracking for 137 as this is a recent regression affecting gdoc. David, could we get a priority/severity set for this bug to facilitate our regression triage? Thanks!

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox137 (nightly). We have limited time to fix this, the soft freeze is in a day. However, the bug still isn't assigned, has low priority and has low severity.

:gcp, could you please find an assignee, increase the priority and increase the severity for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

Greg, you closed the needinfo but didn't triage the bug, comment 4 and 5 are completely misaligned with David setting this P4/S4 (while still leaving this as a tracked bug!).

Can you discuss what the proper priority is and set the P/S/tracking flags appropriately?

Comment 8

[Greg Stoll :gstoll]

Sorry about this.

I agree with :handyman that this is a pretty minor issue - it's just an extra dialog, which is potentially annoying. Also, I don't think we'll show this with ShowBlockedResult set to false, which we expect most DLP vendors to set. (since they want to show their own dialogs)

Comment 9

[Haik Aftandilian [:haik]]

Marking this not block 1882607 due to the problem not occurring when policy setting ShowBlockedResult is set to false. This is the configuration we expect vendors to use so they can show their own block dialogs only.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1936020