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•1 year ago
|
||
(After some discussion, it seems likely that the UI provided won't be a retry UI specifically.)
| Assignee | ||
Comment 2•1 year ago
|
||
Propagate error signal up into nsFilePicker::Open(), to unify error
handling between files and folders.
No functional changes (yet).
Updated•1 year ago
|
| Assignee | ||
Comment 3•1 year 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•1 year 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•1 year 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•1 year 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•1 year 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•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 8•1 year 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•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 9•1 year ago
|
||
DRY up code slightly in preparation for adding a new strategy.
No functional changes.
| Assignee | ||
Comment 10•1 year 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•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 11•1 year ago
|
||
Test that the file-picker-crashed notification appears when the
file-picker utility process is terminated with a file-picker dialog
active.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 12•1 year ago
|
||
Comment 13•1 year 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•1 year 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•1 year 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•1 year ago
|
||
Comment 17•1 year ago
|
||
| bugherder | ||
Description
•