Closed
Bug 845019
Opened 12 years ago
Closed 10 years ago
Update contentAreaUtils.js to use async filepicker open() method
Categories
(Toolkit :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 875731
People
(Reporter: bbondy, Unassigned)
References
Details
Attachments
(2 files)
2.99 KB,
patch
|
jimm
:
review+
|
Details | Diff | Splinter Review |
7.36 KB,
patch
|
mak
:
review-
|
Details | Diff | Splinter Review |
We need to use contentAreaUtils.js in Metro but it uses sync filepickers.
In Metro we can only use async filepickers.
So this bug is to update contentAreaUtils.js to use the async filepicker open() method.
Reporter | ||
Comment 1•12 years ago
|
||
Some uses of filepicker assumes that filter index will work without throwing in JS. This makes that code work.
Attachment #720280 -
Flags: review?(jmathies)
Reporter | ||
Comment 2•12 years ago
|
||
Using this code in Metro now which only has an async filepicker, so need to update this to async.
Attachment #720281 -
Flags: review?(mak77)
Reporter | ||
Updated•12 years ago
|
Attachment #720280 -
Attachment description: Patch v1 → Patch v1 - No throwing for Widget filterIndex
Updated•12 years ago
|
Attachment #720280 -
Flags: review?(jmathies) → review+
Comment 3•12 years ago
|
||
Comment on attachment 720281 [details] [diff] [review]
Patch v1 - Use async filepicker in toolkit/content/contentareautils.js
Review of attachment 720281 [details] [diff] [review]:
-----------------------------------------------------------------
luckily looks like the various internalSaveURL() consumers don't expect it to be synchronous, otherwise would have been a nightmare... I would still suggest doing a tryrun with the final patch and retrigger mochitests multiple times to be sure it's not going to add any unexpected intermittent failure, since it's hard to poll all tests to verify they don't expect things to happen synchronously.
::: toolkit/content/contentAreaUtils.js
@@ +278,5 @@
>
> // Note: aDocument == null when this code is used by save-link-as...
> var saveMode = GetSaveModeForContentType(aContentType, aDocument);
>
> var file, sourceURI, saveAsType;
with the callback these may now be pointless, see below.
@@ +284,5 @@
> + function fpCallback(aFile) {
> + if (!aFile) {
> + return;
> + }
> + saveAsType = fpParams.saveAsType;
this differs from the previous implementation, in the if (aChosenData) case it was always using kSaveAsType_Complete, and in such case fpParams is undefined, that means this will throw
Looks like we may need a new test for this particular code path if no test is failing due to this
@@ +285,5 @@
> + if (!aFile) {
> + return;
> + }
> + saveAsType = fpParams.saveAsType;
> + file = fpParams.file;
same issue, actually this should probably use aFile, but it's pointless, just use aFile later...
@@ +317,5 @@
> // FileName/Extension will be ignored if aChosenData supplied.
> if (aChosenData) {
> file = aChosenData.file;
> sourceURI = aChosenData.uri;
> saveAsType = kSaveAsType_Complete;
these assignments are now basically unused.
@@ +536,5 @@
> * An nsIURI associated with the download. The last used
> * directory of the picker is retrieved from/stored in the
> * Content Pref Service using this URI.
> * @return true if the user confirmed a filename in the picker or the picker
> * was not displayed; false if they dismissed the picker.
This patch is removing the only case where this function was returning false, so the return value should be removed and the following test should be improved (likely using the callback) http://mxr.mozilla.org/mozilla-central/source/browser/components/privatebrowsing/test/browser/perwindow/browser_privatebrowsing_downloadLastDir_c.js#69
you should document the callback param too.
From what I see the callback is invoked only if the dialog has been opened for user interaction since the early return here is unhandled:
http://mxr.mozilla.org/mozilla-central/source/toolkit/content/contentAreaUtils.js#560
I'm not sure if this is the expected behavior, looks like that early return may also want to callback with the found target file, especially since internalSave (the other method you are changing here) looks may be relying on that early return.
Based on this it's likely the PB test above is not really testing what it tries to tell us...
@@ +609,5 @@
>
> + let fpCallback = function fpCallback_done(aResult) {
> + if (aResult == Ci.nsIFilePicker.returnCancel || !fp.file) {
> + aCallback(null);
> + } else {
just early return to avoid having to brace and indent all the else
Attachment #720281 -
Flags: review?(mak77) → review-
Reporter | ||
Updated•11 years ago
|
Assignee: netzen → nobody
Assignee | ||
Updated•10 years ago
|
OS: Windows 8 Metro → Windows 8.1
Comment 4•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•