Closed Bug 865803 Opened 7 years ago Closed 7 years ago
Unable to save Scratchpads, Style Editor, about:memory, ... on OS X
Tried saving a Scratchpad on Nightly and am getting: -- [14:46:58.105] TypeError: fp.file is null @ chrome://browser/content/scratchpad.js:1001 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130423 Firefox/23.0"
hg blame on that line points to: Bug 781973 - Use filepicker's open() instead of the obsolete show() in /browser. r=bbondy
Depends on: 781973
Also breaks the save feature in the Style Editor.
Places dialog, Export Bookmarks.
Sync Prefs, Save recovery key... http://mxr.mozilla.org/mozilla-central/source/browser/base/content/sync/utils.js#177
tested and bug not present on Fx19, 20.
a new suspicious change: http://hg.mozilla.org/mozilla-central/filelog/6e51c05eee68/widget/cocoa/nsFilePicker.mm
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #742459 - Flags: review?(joshmoz)
Can we write a test for this?
This breaks addons that use the file picker too, like Fabrice's b2gremote addon.
(In reply to :Gavin Sharp (use email@example.com for email) from comment #10) > Can we write a test for this? The filepicker API blocks until the user responds to the dialog. So, only if we have a test framework in which we can interact with the system's native dialogs. Do we? I am not aware of one. :-(
(In reply to Rob Campbell [:rc] (:robcee) from comment #8) > a new suspicious change: > > http://hg.mozilla.org/mozilla-central/filelog/6e51c05eee68/widget/cocoa/ > nsFilePicker.mm When saving the ScratchPad, execution doesn't reach nsFilePicker::PutLocalFile, so the native file save dialog is not displayed. By contrast, nsFilePicker::PutLocalFile is called by "Save Page As…" and performs as expected. The call chain is probably different and likely short returns on the way to calling PutLocalFile. We have to investigate this. (In reply to :Gijs Kruitbosch from comment #9) > Created attachment 742459 [details] [diff] [review] > Nullcheck theDir before converting to a URL theDir is checked for null a few lines above, and we make sure it's assigned either @"" or @"/Applications" so it can't be null any more.
Well, sorry, theDir is checked for null only in GetLocalFiles. And indeed an exception is thrown in PutLocalFile at [thePanel setDirectoryURL:[[NSURL alloc] initFileURLWithPath:theDir isDirectory:YES]] when theDir is null. But why is theDir set when saving a page, and null when saving the scratchpad?
(In reply to André Reinald from comment #14) > Well, sorry, theDir is checked for null only in GetLocalFiles. And indeed an > exception is thrown in PutLocalFile at > [thePanel setDirectoryURL:[[NSURL alloc] initFileURLWithPath:theDir > isDirectory:YES]] when theDir is null. > > But why is theDir set when saving a page, and null when saving the > scratchpad? Because you're allowed to not set it and have it use the last-used directory (OS X keeps track of that), rather than a pre-set one.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 23
You need to log in before you can comment on or make changes to this bug.