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
- Make the block dialog modal (instead of an OS notification) and use UX strings
- Make the warn dialog not have a default choice on it
Differential Revision: https://phabricator.services.mozilla.com/D206813
Note that this also covers the case when the connection initially succeeds but then the agent goes away - we hope to handle this better in bug 1888293. This also shows a message if the signature verification fails.
Differential Revision: https://phabricator.services.mozilla.com/D206024
