Closed Bug 865803 Opened 7 years ago Closed 7 years ago

Unable to save Scratchpads, Style Editor, about:memory, ... on OS X

Categories

(DevTools Graveyard :: Scratchpad, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 23

People

(Reporter: rcampbell, Assigned: Gijs)

References

Details

Attachments

(1 file)

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.
also, about:memory
Summary: Unable to save Scratchpads on OS X → Unable to save Scratchpads, Style Editor, about:memory, ... on OS X
Places dialog, Export Bookmarks.
tested and bug not present on Fx19, 20.
bug not present in aurora, fx22.
No longer depends on: 781973
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #742459 - Flags: review?(joshmoz)
Depends on: 802776
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 gavin@gavinsharp.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.
Attachment #742459 - Flags: review?(joshmoz) → review+
https://hg.mozilla.org/mozilla-central/rev/dbe8ad85f359
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 23
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.