Provide UI notification when the out-of-process file-picker crashes
Categories
(Core :: Widget: Win32, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox130 | --- | fixed |
People
(Reporter: rkraesig, Assigned: rkraesig)
References
(Blocks 1 open bug)
Details
Attachments
(7 files, 3 obsolete files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
When the out-of-process file-picker crashes, we currently restart in-process. If it wasn't an instacrash, this is likely to be confusing. If it was, it'll just bring down the browser.
We should probably notify the user instead, giving them an option to retry or (in the case of save-dialogs) to just save to a temporary or default location.
Assignee | ||
Comment 1•11 months ago
|
||
(After some discussion, it seems likely that the UI provided won't be a retry UI specifically.)
Assignee | ||
Comment 2•9 months ago
|
||
Propagate error signal up into nsFilePicker::Open(), to unify error
handling between files and folders.
No functional changes (yet).
Updated•9 months ago
|
Assignee | ||
Comment 3•9 months ago
|
||
nsIExternalHelperAppService computes, but does not expose, the preferred
downloads directory's location. Expose it, for use by default-save-location
fallback code when the file-dialog fails.
Additionally, add a test to confirm that the value produced by this
method is, as the comment nearby implies, the same as that produced by
the eponymous method on DownloadIntegration
.
Assignee | ||
Comment 4•9 months ago
|
||
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.
Assignee | ||
Comment 5•9 months ago
|
||
Implement ForwardingObserver
, which acts as a proxy observer-service.
If a message is sufficiently rare, it may be desirable to avoid loading
the module implementing its handling until actually necessary.
ForwardingObserver
allows lazy registration of observers for such
events; one instead registers an observer-getter, which will not be
invoked until and unless the relevant message is sent.
(Credit to :Gijs for the suggestion.)
Assignee | ||
Comment 6•9 months ago
|
||
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.
Assignee | ||
Comment 7•9 months ago
|
||
Now that we have a mechanism to report file-dialog failure to the user,
turn off the in-process fallback by default.
(The in-process fallback is still available if enabled explicitly --
in which case the failure message won't be shown, unless by some miracle
the in-process file-dialog fails without crashing.)
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Comment 8•9 months ago
|
||
Comment on attachment 9408304 [details]
Bug 1884426 - [2/5] Add method to get downloads directory r?Gijs
Revision D214189 was moved to bug 1904160. Setting attachment 9408304 [details] to obsolete.
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Assignee | ||
Comment 9•8 months ago
|
||
DRY up code slightly in preparation for adding a new strategy.
No functional changes.
Assignee | ||
Comment 10•8 months ago
|
||
... and set this as the new default strategy on Nightly.
Note that the file-picker failure UI will still be displayed if the
file-dialog encounters a nonfatal local failure as well.
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Assignee | ||
Comment 11•8 months ago
|
||
Test that the file-picker-crashed notification appears when the
file-picker utility process is terminated with a file-picker dialog
active.
Updated•8 months ago
|
Updated•8 months ago
|
Comment 12•8 months ago
|
||
Comment 13•8 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6e0849feca9b
https://hg.mozilla.org/mozilla-central/rev/23bba9b337d7
https://hg.mozilla.org/mozilla-central/rev/b0a5e530a5b4
https://hg.mozilla.org/mozilla-central/rev/340686fd504b
https://hg.mozilla.org/mozilla-central/rev/d97d123115e5
https://hg.mozilla.org/mozilla-central/rev/7635ab5e3dcf
Assignee | ||
Comment 14•6 months ago
|
||
As a followup to the content patches of a couple of months ago: document
the meaning of the values of AsyncExecute's enum Strategy
, and in
particular the reasoning behind the last strategy's heuristic.
No functional changes; this patch only adds comments.
Comment 15•6 months ago
|
||
A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)
Comment 16•6 months ago
|
||
Comment 17•6 months ago
|
||
bugherder |
Description
•