1899815 - The page becomes unresponsive until the messages are closed if the DLP scan/warning is triggered across multiple tabs

Status: NEW

(Firefox :: Data Loss Prevention, defect)

Description

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

Attachment: dlp_two_scans.gif

Found in

• 128.0a1 (2024-05-30)

Affected versions

• 128.0a1 (2024-05-30)

Tested platforms

• Affected platforms: Windows 10x64, Windows 11x64
• Unaffected platforms: macOS, UbuntuUbuntu 22, macOS

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

Steps to reproduce

1. Open https://en.wikipedia.org/wiki/UNESCO in two tabs.
2. Paste “warning text” in both tabs.
3. Focus on the first tab and choose Cancel or Use content.
4. Navigate on the webpage.

Expected result

• Navigation is possible.

Actual result

• Page is unresponsive until the second tab finishes scanning or the warning dialog is closed.

Regression range

• Not a regression. New feature.

Additional notes

• Attached a screen recording.
• This issue only happens if pasting the second content while the firs scan was not finished inside the DLP agent.
• Pasting a second time on an unresponsive page will make the page blank with a loading circle in the center until all DLP messages are closed.
• THis happens while the scanning and warning messages are displayed. This does not happen while a blocking message is displayed.

Comment 1

[Greg Stoll :gstoll]

When reproducing this, I can confirm that the two tabs are in separate content processes, which eliminates some possibilities for what's going on here.

Comment 2

[Greg Stoll :gstoll]

OK, I know more or less what's going on here; we're paying for our sins in dealing with the fact that pasting is a synchronous operation.

To do content analysis on the first paste, the main thread of the parent process gets a GetClipboard message over IPC and ends up in ContentAnalysis::CheckClipboardContentAnalysisSync. To do this synchronously, it uses SpinEventLoopUntil to wait for the result of the content analysis, which enables it to still respond to other messages.

So when the second paste happens, the main thread of the parent process gets another GetClipboard message and ends up calling CheckClipboardContentAnalysisSync further up in the same call stack. This means that the first content analysis can't be completed until the second one is. (for these purposes, "completed" does not include getting a WARN result, as that doesn't get passed back to the caller since it requires the user to choose ALLOW or BLOCK, so this explains why seeing the "busy" dialog and "warn" dialog both have the same effects)

Comment 3

[Greg Stoll :gstoll]

This is a similar issue to bug 1858507