One annoying part to this is that for "Save As" downloads on a PDF (for
example), we don't get a valid browsing context. For downloads, the only
thing we need a browsing context for us to get a window so we can show
the "DLP busy" notification, so just use the window that we were
initialized with. In practice I can't tell any difference.
Original Revision: https://phabricator.services.mozilla.com/D251880
Differential Revision: https://phabricator.services.mozilla.com/D258204
Content Analysis needs to be able to show a tab-modal dialog in the
sidebar, in case users paste text into a GenAI chatbot, etc. The dialogs
need to be tab-modal because the "DLP busy" dialog needs to be closable
by the JS code when the operation is done.
This change detects whether a dialog is trying to be displayed from a
browser inside the sidebar and shows it correctly.
Note that this does not change how extensions behave; if they try to
display a tab-modal dialog it will end up being window-modal (see
discussion in bug 1680066 and bug 1513656). I had a patch to fix this
but ran into some window leaks during tests that I was unable to address.
Differential Revision: https://phabricator.services.mozilla.com/D242957
The fix to bug 1963360 broke cancelling in the dialog. This is a small
fix but I also added a few tests around the busy/cancel dialog, which
will hopefully prevent these kinds of regressions in the future.
Differential Revision: https://phabricator.services.mozilla.com/D248103
When we close the DLP busy dialog programmatically, we shouldn't cancel
associated user actions. This can cause a problem if we're analyzing files
in batch mode (since once one operation finishes, it will cancel the other
selected files). It can also cause problems with WARN responses, since it
will cancel the operation before the user can select ALLOW or BLOCK.
I have on my list to add tests for the WARN dialog, which I'll hopefully
get around to soon and I think would have caught this.
Differential Revision: https://phabricator.services.mozilla.com/D247320
Since the cancel dialog is only associated with one user action ID, and a
folder check now uses different user action IDs for each file, user-cancel
needs to cancel all of the associated user action IDs. (Other cancel
reasons will not want that behavior.)
This patch adds a set of these compound actions to the service. Each entry
is the complete set of user action IDs that constitute the compound action.
The set is held until the compound action issues a response.
Differential Revision: https://phabricator.services.mozilla.com/D246160
Since the cancel dialog is only associated with one user action ID, and a
folder check now uses different user action IDs for each file, user-cancel
needs to cancel all of the associated user action IDs. (Other cancel
reasons will not want that behavior.)
This patch adds a set of these compound actions to the service. Each entry
is the complete set of user action IDs that constitute the compound action.
The set is held until the compound action issues a response.
Differential Revision: https://phabricator.services.mozilla.com/D246160
This required a few changes to ContentAnalysis.sys.mjs to:
- allow using an overridden nsIContentAnalysis and calling initialize()
again so it will reevaluate whether content analysis is active and set
up the needed observers to show dialogs.
- clean up some logic about setting up and tearing down observers
This should let us test more dialogs in the future - I'm starting with
the quit confirm dialog because it's been a problem before.
Differential Revision: https://phabricator.services.mozilla.com/D245572
This will enable VS Code to do type-checking on these files. Most of
the problems it found were fairly trivial (or wrong type declarations),
but the extra call to _removeSlowCAMessage() seems like a real problem
(will flag in the review)
Differential Revision: https://phabricator.services.mozilla.com/D245625
Per the comment, the quit-application event can be delayed if the user
quits via keyboard or the hamburger menu (as opposed to simply closing
the last window). I didn't dig too deep into this but this seems like
the kind of thing we can do in quit-application-granted anyway.
Differential Revision: https://phabricator.services.mozilla.com/D245594
Explicitly cancel pending WARNs when we quit so that the dialogs go away
and nothing gets stuck. I feel like this used to work by coincidence,
but now we do it explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D245291
We handle this similarly to pasting into a prompt() dialog, so I
refactored that logic into a new ContentAnalysisUtils and call it from
both places.
Also drive-by cleanup of BUG_COMPONENT for a few Content Analysis
moz.build's
Differential Revision: https://phabricator.services.mozilla.com/D244818
We handle this similarly to pasting into a prompt() dialog, so I
refactored that logic into a new ContentAnalysisUtils and call it from
both places.
Also drive-by cleanup of BUG_COMPONENT for a few Content Analysis
moz.build's
Differential Revision: https://phabricator.services.mozilla.com/D244818
This prevents CA from showing many busy dialogs, each of which required a
layout reflow. This does not prevent CA from showing many other dialogs
(e.g. block and warn dialogs).
Differential Revision: https://phabricator.services.mozilla.com/D242223
This prevents CA from showing many busy dialogs, each of which required a
layout reflow. This does not prevent CA from showing many other dialogs
(e.g. block and warn dialogs).
Differential Revision: https://phabricator.services.mozilla.com/D242223
I verified that this fixes the problem in this bug and does not regress
bug 1928064.
The problem was that if only one request was being made with the same
user action ID, the otherEntries would always be empty, and so we would
not show the dialog. Now we handle multiple requests by removing their
info from requestTokenToRequestInfo, and thus when we get the
"dlp-request-made" notification we will exit early and not show a dialog.
Differential Revision: https://phabricator.services.mozilla.com/D239755
We are no longer using the grouping by BrowsingContext functionality,
so rename and greatly simplify this class. (not strictly needed for this
change, but simpler is better!)
Differential Revision: https://phabricator.services.mozilla.com/D239397
The changes include:
1. Making various IDL classes builtin.
2. Making nsIContentAnalysisResponse subclass nsIContentAnalysisResult.
3. Making requestToken and userAction fields internal to CA service.
4. Added sourceWindowGlobal (the source of the data to scan) to request and
use it for content-source-is-same-tab determinations.
5. Made nsIContentAnalysisCallback expect a Result, not a Response.
6. Added cancelRequestsByUserAction and renamed cancelContentAnalysisRequest to cancelRequestsByRequestToken (deprecated).
7. Added ability for CancelAllRequests to forbid future requests (not needed but for peace of mind).
8. Added MakeResponseForTest since response is not builtin.
9. Made ContentAnalysis SupportsWeakPtr so that it can be weakly held by the MultipartRequestCallback,
which can't just re-get the service since it doesn't want the mock one.
10. Move SafeContentAnalysisResultCallback functionality to ContentAnalysisCallback.
11. Make various routines use userActionId instead of requestToken.
12. Add MultipartRequestCallback to count that we get the right number of responses.
13. Remove unneeded thread sync behavior. The only part that was kind-of
neeed was to abort behavior on a background thread if the request were
canceled first -- this is a race that we don't need to win so we now just
ignore it and ignore the result (TODO: I'm not positive I send cancel to
the agent in this case).
14. Send cancel to the agent (in all other cancel cases).
15. Simplify the request map, which is now the user action map mUserActionMap.
16. Makes the MultipartRequestCallback the nexus for filtering requests --
this way filters are applied uniformly instead of sometimes-at-some-point-
for-some-use-cases.
17. Adds showBlockedRequestDialog for showing a block dialog when requests
are rejected before they are expanded into their final form.
18. Adds SafeGetStaticErrorName for logging nsresults.
Differential Revision: https://phabricator.services.mozilla.com/D236630
When the DLP agent can't be reached, we enact default DLP behavior based on the
browser.contentanalysis.default_result pref. That still shows result dialogs
for pastes, and when default-warn is enabled, and the messages used for those
when the agent *is* connected would confuse the user here. This changes those
messages.
Differential Revision: https://phabricator.services.mozilla.com/D228233
This uses the already-existing ability of the TabDialogManager to show
a dialog immediately after the previous one closes. So this code doesn't
need to keep track of what dialog to show next - it just displays them
all (and closes them appropriately), and the TabDialogManager will show
them one at a time.
Differential Revision: https://phabricator.services.mozilla.com/D223415
This uses the already-existing ability of the TabDialogManager to show
a dialog immediately after the previous one closes. So this code doesn't
need to keep track of what dialog to show next - it just displays them
all (and closes them appropriately), and the TabDialogManager will show
them one at a time.
Differential Revision: https://phabricator.services.mozilla.com/D223415
For BLOCKED text, if we do two requests in quick succession, we will now
return a cached result for the second request. This patch avoids showing
the BLOCK dialog more than once. (also works for WARN)
Differential Revision: https://phabricator.services.mozilla.com/D219496
A new attempt to fix these problems - always use asynchronous dialogs, but in the print preview case show the "DLP blocked" dialog on the original browsingContext that displayed the print preview dialog (since the dialog itself is about to close)
Differential Revision: https://phabricator.services.mozilla.com/D212815
I verified that quitting while the synchronous version of the dialog is active doesn't hang, so we're not re-regressing bug 1898718.
Differential Revision: https://phabricator.services.mozilla.com/D212189
