... and set this as the new default strategy on Nightly.
Note that the file-picker failure UI will still be displayed if, e.g.,
the file-dialog encounters a nonfatal local failure after a nonfatal
remote failure.
Differential Revision: https://phabricator.services.mozilla.com/D215559
Fire a signal (via the observer service) when the file-dialog crashes or
otherwise fails.
Set up a listener for that signal which reports the failure to the
end-user via the NotificationBox.
Differential Revision: https://phabricator.services.mozilla.com/D214192
If the user is trying to save a file, don't discard that file on
failure; instead, write it to some default location on the filesystem.
Differential Revision: https://phabricator.services.mozilla.com/D214190
Propagate error signal up into nsFilePicker::Open(), to unify error
handling between files and folders.
No functional changes (yet).
Differential Revision: https://phabricator.services.mozilla.com/D214188
Additionally, fix a schema error: `data-sensitivity` was under
`metadata`, and also should have been spelled with an underscore.
Differential Revision: https://phabricator.services.mozilla.com/D213834
* Adjust UtilityProcess{Host,Manager} to propagate ipc::LaunchErrors for
their clients, or to create new ones where none previously existed.
* Adjust the various clients of the above to to handle the additional
information -- mostly by adding the additional failure-location data
to log messages.
* Fix an unrelated bug wherein the return type of `LaunchProcess` was
declared as exclusive, despite being cached and reused.
In particular, filedialog::Error objects should now contain -- and report
to telemetry without further adjustment -- the actual error code from
`ipc::LaunchError`s.
(Reporting the original failure location as well will occur in bug
1884221.)
Differential Revision: https://phabricator.services.mozilla.com/D209715
We used to use GetDomFileOrDirectory(), but that creates a mozilla::dom::Directory which needs to be able to get a DOMWindow. Getting that DOMWindow is now failing, perhaps because of the out-of-process file picker?
Anyway, all we care about is getting the contents of the directory, so we can just use GetDirectoryEntries() to sidestep this, and it also makes the code a bit simpler.
Unfortunately there isn't a good way to test code that's in nsFilePicker.cpp right now, as MockFilePicker mocks all of this out.
Differential Revision: https://phabricator.services.mozilla.com/D209056
Instead of passing potentially-dynamic strings over the IPDL interface,
pass an integer which corresponds to one of a fixed set of static
strings. (This is basically an enum with more steps -- or with fewer
steps, depending on which side of it you're standing on.)
This ensures that the set of possible location-strings is fixed, which
in turn both ensures that aggregation of telemetry stays relatively
simple and guards against accidental leakage of PII thereinto. (Or,
alternatively and equivalently, this minimizes the code region that
data-review needs to consider once the location string is reported to
telemetry.)
Note that we do not yet actually report the location-string via
telemetry; that's planned to occur in bug 1884221.
Differential Revision: https://phabricator.services.mozilla.com/D205169
Don't crash the file-picker host process just because a nonfatal failure
occurred. Instead, report the failure location and code over the IPDL
interface.
Differential Revision: https://phabricator.services.mozilla.com/D205168
Replace most promise-types in widget/windows/filedialog with something
capable of carrying the initial cause and location of a failure.
This does not properly convey that metadata across the IPDL connection
where possible; that will be done in an upcoming commit.
Differential Revision: https://phabricator.services.mozilla.com/D205167
The `Show{File,Folder}Picker{Local,Remote}` functions don't depend on
anything in `nsFilePicker` itself except the mostly-vestigial promise
type. Pull all of them into nsFilePicker.cpp as static functions in an
anonymous namespace.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D205166
ThenCommands are effectively linear: they can only be used once. Make
this restriction more difficult to accidentally violate by applying
MOZ_TEMPORARY_CLASS.
Fix the one line of code that this breaks. Castigate its author (who is
also the author of this commit) accordingly.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D200061
Check the URLs in the request against the prefs
browser.contentanalysis.allow_url_regex_list and
browser.contentanalysis.deny_url_regex_list, which are space-separated
lists of ECMAscript regexs that match against ASCII-encoded URLs.
Differential Revision: https://phabricator.services.mozilla.com/D203508
Check the URLs in the request against the prefs
browser.contentanalysis.allow_url_regex_list and
browser.contentanalysis.deny_url_regex_list, which are space-separated
lists of ECMAscript regexs that match against ASCII-encoded URLs.
Differential Revision: https://phabricator.services.mozilla.com/D203508
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
Eliminate `WindowEnabler` by folding it into `nsWindow::PickerOpen()`
and `nsWindow::PickerClosed()`. This avoids the implicit assumption that
multiple instances are created and destroyed in LIFO order.
Differential Revision: https://phabricator.services.mozilla.com/D200742
Remove an unnecessary member function from AutoWidgetPickerState.
Additionally, use a safer method of getting the underlying nsWindow than
`static_cast`, and add some thread-safety assertions in
nsWindow::Picker{Open,Closed}().
No functional changes on the happy path.
Differential Revision: https://phabricator.services.mozilla.com/D200741
As much as I like the "all-static uninstantiable struct" projection of
Rust-style modules, they're an unnecessary weirdness in C++.
Shuffle the code around to just use a collection of nested namespaces.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D197627
Add a new Glean event for the out-of-process file-dialog, marking when
it breaks and forces us to fall back to the existing in-process
behavior.
This creates a new nested pseudo-namespace struct, which is just weird
enough that it probably needs to be replaced with a true namespace. That
will be done in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D197626
As much as I like the "all-static uninstantiable struct" projection of
Rust-style modules, they're an unnecessary weirdness in C++.
Shuffle the code around to just use a collection of nested namespaces.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D197627
Add a new Glean event for the out-of-process file-dialog, marking when
it breaks and forces us to fall back to the existing in-process
behavior.
This creates a new nested pseudo-namespace struct, which is just weird
enough that it probably needs to be replaced with a true namespace. That
will be done in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D197626
Pull the async-to-sync transition down one (or two) class-layers, while
pulling the sync-to-async transition up one more function layer. This
allows them to meet in a single function -- where they cleanly annihilate.
This is a _significant_ functional change, as it leaves the file-dialog
implementation fully asynchronous on Windows! \o/
Differential Revision: https://phabricator.services.mozilla.com/D193740
Pull the sync-to-async boundary up another function-call layer. This
unifies the file- and folder-picker sync-to-async boundaries.
Again, no functional changes except for the migration of a tiny bit of
glue code.
Differential Revision: https://phabricator.services.mozilla.com/D193739
Pull the sync-to-async boundary up one function-call layer, from
`ShowXxxPicker{Local,Remote}` to `ShowXxxPicker`. This coalesces the
remote and local sync-to-async boundaries.
Additionally, standardize on exclusive MozPromises, since none of them
happen to need multiple listeners.
This is arguably, but not practically, a functional change, as a tiny
bit of glue code is now executed on a different thread.
(N.B.: While this reduces the total number of sync-to-async boundaries
back down to two, this is not the removal promised in the previous
commit summary.)
Differential Revision: https://phabricator.services.mozilla.com/D193738
When opening a file dialog locally (that is, in the parent process), do
so asynchronously on a separate thread.
Since the calling code is still synchronous, this necessitates adding
new calls to `ImmorallyDrivePromiseToCompletion` at the sync-to-async
boundary. These are _very_ temporary -- they'll be removed before this
patchset is done.
Differential Revision: https://phabricator.services.mozilla.com/D193737
We're about to add some code that will actually create a file dialog,
rather than just the actor, asynchronously. Rename this function to make
it clear which of those it does.
(That it does so asynchronously is probably sufficiently communicated by
the return type.)
Differential Revision: https://phabricator.services.mozilla.com/D193733
Ray Kraesig