1936500 - An incorrect paste event is displayed after pasting a blocked file

Status: RESOLVED INVALID

(Firefox :: Data Loss Prevention, defect)

Description

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: image.png

Found in

• 135.0a1 (2024-12-10)

Affected versions

• 135.0a1 (2024-12-10)
• 134.0b8

Tested platforms

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

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
• DLP Agent is running: .\content_analysis_sdk_agent.exe --user --toblock=.*\d{3}-?\d{2}-?\d{4}.* --towarn=.*warn.* --delays=10

Steps to reproduce

1. Open https://madebyevan.com/clipboard-test/ and paste a blocked file (e.g 123456789.txt)

Expected result

• The correct paste event is displayed:

types: 2 types
type: application/x-moz-file
type: Files
files: 0 files
items: 1 items
item: file (application/x-moz-file)

Actual result

• The following paste event is displayed:

types: 0 types
files: 0 files
items: 0 items

Regression range

• The issue happens after bug 1915351.

Additional notes

• Attached a screenshot.

Comment 1

[BugBot [:suhaib / :marco]]

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

For more information, please visit BugBot documentation.

Comment 2

[Greg Stoll :gstoll]

I know this is a change in behavior but this might be fine.

Comment 3

[David Parks [:handyman]]

Isn't this the right behavior? Since the file is blocked, it shouldn't be in the dataTransfer?

Comment 4

[Greg Stoll :gstoll]

After talking with David we both think this is correct behavior (more correct than the previous behavior, anyway). Alexandru - can you update the test plan to check for this new behavior? Then we can close this bug.

Thanks!

Comment 5

[Alexandru Trif, Desktop Test Engineering [:atrif]]

(In reply to Greg Stoll :gstoll from comment #4)

After talking with David we both think this is correct behavior (more correct than the previous behavior, anyway). Alexandru - can you update the test plan to check for this new behavior? Then we can close this bug.

Thanks!

Sure thing. I updated the test case that failed for this scenario. I don't have permission to edit the DLP Test Plan as well. Closing this as invalid per the above comments. Thank you!

Comment 6

[Greg Stoll :gstoll]

Thanks! I've updated the test plan Google Doc as well.