1950878 - The use content windows are displayed late on multiple file uploads after the scanning is completed when TimeoutResult is set to 1

Status: NEW

(Firefox :: Data Loss Prevention, defect)

Description

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

Attachment: multiple_uploads_dlp.gif

Found in

• 137.0a1 (20250227090415)

Affected versions

• 137.0a1 (20250227090415)

Tested platforms

• Affected platforms: Windows 10x64
• Unaffected platforms: Ubuntu 24, 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-4.json to it and then rename it to policies.json
• replace "DefaultResult": 1 with "TimeoutResult": 1 in policies.json file
• 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 Firefox and https://mdn.github.io/learning-area/html/forms/file-examples/simple-file.html
2. Choose multiple file to upload.
3. Wait for the scans to be completed.

Expected result

• The use content window is displayed.

Actual result

• The use content window is displayed only after some time.

Regression range

• Before bug 1949834 and after bug 1944395Firefox crashes when performing multiple uploads. So this might not be a regression.

Additional notes

• Attached a screen recording.

Comment 1

[David Parks [:handyman]]

Attachment: bug1950878.mp4

I can't make heads or tails of this.

The agent log shows some of what's happening, especially at the end, but that goes by far too quickly so I'm uploading an mp4 of the video that can be paused. The policy file sets the timeout (per item) to 5 seconds and there are 7 items, so the first scan by the agent would timeout in 35 seconds and it waits 10, then the second would timeout in 25 seconds and waits 10, and so on. Halfway through the fourth item the time left reaches 0 seconds -- the browser sends cancel to the agent and uses the timeout_result action "1" (warn) for the rest of the responses. However, it appears to wait for the next response from the agent before posting those dialogs, but that's not what's happening.

This profile is similar to comment 0 but involved 9 files. The item count is important -- this doesn't repro e.g. with 3 files at 5 second timeout per file and a 10-second agent delay per file. I'm pretty sure anything greater than 5 or 6 will repro. It seems to show some behaviors that are hard to understand or believe:

• You can't focus on the dlp-response message in the call tree view anymore but you can search it in the stack view to find where it was used and manually focus from there, or manually pull the times for it from the marker view and focus on those. Doing this shows that the first four dlp-responses were from the agent, then five from timeout-cancelling at around 56.58s, then four at 74.96s when those timeout-cancelled-warn-dialogs are dismissed by clicking a button. Why that's four and not five, I don't know, but it probably is because I chose cancel for the first dialog, which aborted the rest of the transaction, and the others are canceled as NS_ERROR_ABORT (not timeouts) and probably dlp-response isn't sent for the one I canceled. (Note that I still had to respond to the other now-useless warn dialogs, which is a bug, although it would be expected if we had bug 1950424 -- but we don't yet.)
• We can see by searching for CancelWithError or abortDialogs (again, using the stack view because the call tree view doesn't allow this anymore) that dlp-response is sent immediately from the CancelWithError call that we do on timeout (at around 56.59s), and that it immediately calls _disconnectFromView/abortDialogs (which is why the busy dialogs are removed). That observer makes only one async JS call, to _showCAResult... and the call doesn't happen until about 71.48s. The system is basically dormant during that time. ¯_(ツ)_/¯

Comment 2

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

The severity field is not set for this bug.
:handyman, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Haik Aftandilian [:haik]]

Making this not a blocker for bug 1882607 because we expect the timeout values used to be multiple minutes meaning that a small delay between the scan finishing and the prompt display is not likely to be noticed. The default timeout value is 300 seconds.