1898740 - Clicking navigations buttons while the DLP dialog is open will lead to actions being executed once the DLP dialog is closed

Status: NEW

(Firefox :: Data Loss Prevention, defect)

Description

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

Attachment: actions being automatically performed after dismissing the DLP dialog

Found in

• 128.0a1 (2024-05-23)

Affected versions

• 128.0a1 (2024-05-23)

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

Tested platforms

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

Steps to reproduce

1. Navigate to yahoo.com
2. Open up a document in an external program (for example Notepad) and type “sample text” into it and copy it
3. Return to Firefox and paste the “sample text” into the search bar at the top of the page
4. Wait for the “You’re not permitted..” dialog to be shown and then press the “Go back” button from the browser toolbar
5. Press the “OK” button from the dialog
6. Observe the behavior

Expected result

• The dialog is dismissed and the user remains on the same page

Actual result

• The dialog is dismissed but the browser navigates to the previous page

Regression range

• This is not a regression as this is a new feature

Additional notes

• See the attached video
• Also reproducing with the “Refresh” button from the toolbar / zoom buttons from the app meu
• Also reproducing while the sample DLP agent is running

Comment 1

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

Attachment: Tab not entirely blocked while a DLP message is active

I have encountered a slightly different behavior related with the browser navigation buttons while a DLP message is active, as follows:

1. Go to https://codepen.io/gregstoll/full/VwqmqWo
2. Copy some text from an external program and paste it into the text box after pressing the "Prompt" button
3. Press the “Go back” button from the browser toolbar while the DLP message is still shown

AR: The browser navigates to the previous page while the DLP message is active (attaching a video as well)

Note: Also reproducing while being in the Print Preview window and a DLP message is active or when uploading a file on https://cgi-lib.berkeley.edu/ex/fup.html.
Not reproducing for support.mozilla.org / wikipedia.org / yahoo.com webpages

Comment 2

[Greg Stoll :gstoll]

This might be fixed by the fix to bug 1898718, fwiw

Comment 3

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

Attachment: recording showing the behavior

Verified this using Firefox Nightly 128.0a1, build ID 20240529214854 on Windows 11 and the following were noticed:

• when interacting with the navigation buttons from the browser toolbar while the DLP blocked dialog is shown, the dialog is automatically dismissed and the browser responds to the performed action. Zooming in from the app menu is also possible while the blocked dialog is shown - I will attach a video as well. @gstoll, is this the desired behavior? We would expect to not be able to interact with the tab while a DLP dialog is open regardless of its content (blocked, progress or warn dialog)
• when interacting with the navigation buttons from the browser toolbar / zoom buttons while the "Scan in progress" or "This content may be unsafe" dialog is shown, the behavior described in Comment 0 still applies -> the browser responds to the performed action only after dismissing the dialog

Could you please let us know which is the expected behavior in this case? Thank you in advance!

Comment 4

[Greg Stoll :gstoll]

The dialogs are intended to block interaction with the page until the DLP request is done. But if the user wants to go back, or close the tab, etc. there's no reason to stop them; ideally this would just cancel the DLP request. So the first behavior in comment 3 is desired. However, the second behavior doesn't sound that bad to me, especially because if the user really wants to do something they can just cancel the DLP operation.

So let's leave this bug open tracking the second behavior. Thanks for your detailed responses!