802776 - nsIFilePicker.displayDirectory is broken on Mac ([NSOpenPanel setDirectoryURL:x], x is a local path, not a URL warning from in nsFilePicker::GetLocalFiles)

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Eric Promislow]

Attachment: check_convert_dir.patch

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0) Gecko/20100101 Firefox/10.0
Build ID: 20120129021758

Steps to reproduce:

Called nsFilePicker::GetLocalFiles with a mDefaultDirectory set to an nsILocalFile object localFile, initialized by calling localFile.initWithPath(<local path>);


Actual results:

Cocoa emits this error message, and opens in my home directory instead of the one I specified:

2012-10-17 12:07:23.197 komodo-bin[97350:1203] Invalid URL passed to an open/save panel: '/Users/ericp/lab/komodo/bugs/ruby'.  Using 'file://localhost/Users/ericp/' instead.



Expected results:

It should follow the defaultDirectory directive.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

As with bug 802328, could you write a simple testcase and attach it to this bug?

Comment 2

[Eric Promislow]

I wrote an extension, but can't duplicate the
bug in Firefox-Aurora (Komodo is currently
on Mozilla 17). FWICT we're executing the
same code.

I welcome instructions on writing a standalone testcase
for this. I didn't see how, so I wrapped it in an
extension.

You can find it at

http://bentframe.org/openfile01_extension-0.3-ko.xpi

There's a hardwired path in the .js file that will need
changing.  This code will trigger bug 802328 as well

Comment 3

[Eric Promislow]

Attachment: Code for triggering the error message.

Same code wrapped by the "openfile01" extension.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

I can't reproduce this, either with your extension from comment #3 or mine from bug 802328 comment #3 (attachment 679889 [details]).

Apparently (judging from comment #2) you can't reproduce this with your extension, either.

If/when you do find a way to reproduce either this bug or bug 803238, please let us know.  In the meantime I'll close both bugs WORKSFORME.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

I can reproduce this bug with the following steps. I'm running OS X 10.7.5 with a recent trunk build.

1) Launch Nightly with a new profile
2) Press Cmd+O
Result:
firefox[1032:503] Invalid URL passed to an open/save panel: ''.  Using 'file://localhost/Users/gavin/...' instead.

(where "..." is the path to the last directory from which I opened a file using a native file picker).
3) Open a file from any directory (I chose my home directory).
4) Press Cmd+O again
Result:
firefox[1032:503] Invalid URL passed to an open/save panel: '/Users/gavin'.  Using 'file://localhost/Users/gavin/' instead.

Seems like maybe nsFilePicker::PanelDefaultDirectory needs to do a different type of conversion (from file path to file URI?) to match what setDirectoryURL expects?

Comment 6

[Steven Michaud [:smichaud] (Retired)]

> (where "..." is the path to the last directory from which I opened a
> file using a native file picker).

Were you using this "native file picker" from Firefox, or from some
other app?  If so which other app?  And if the app was Firefox, I
wonder why the "last directory" setting carried over to a new profile.

Let me try using your STR to reproduce this bug -- but I suspect I
won't be able to.  If it were so easily reproducible, I'm pretty sure
I would have seen it before myself -- and I'm quite sure I haven't.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> 1) Launch Nightly with a new profile

Exactly how did you do this?  With the Profile Manager?

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Never mind, Gavin.

I *was* able to reproduce this using your STR from comment #5.  I tested with a recent mozilla-central nightly (2013-04-11) on OS X 10.7.5.  I used the Profile Manager to start it with a new profile.

I didn't see any other problems than the error messages in the system console.  There were no glitches in the UI, and I had no problems opening files.  So this is a pretty minor bug.

Given this and the fact that I'm so busy, I doubt that I'll be able to get to this bug in the foreseeable future.  But maybe we can find someone else to work on it.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

André:  If you're not busy with other bugs, you might want to take a look at this.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

(In reply to Steven Michaud from comment #6)
> Were you using this "native file picker" from Firefox, or from some
> other app?  If so which other app?  And if the app was Firefox, I
> wonder why the "last directory" setting carried over to a new profile.

I assumed there was some global system "last used directory" that it fell back to when given an invalid argument. But the previous use of the file picker was indeed with a different build of Firefox, which may have had the same bundle ID, so it's possible that it's keyed on application name or ID as well I guess.

And yes, I was launching Firefox from the profile manager.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

(In reply to Steven Michaud from comment #8)
> I didn't see any other problems than the error messages in the system
> console.  There were no glitches in the UI, and I had no problems opening
> files.  So this is a pretty minor bug.

Firefox attempts to save the "last used directory" (it even stores separate "last used directory" values per-domain, for file-pickers opened from <input type="file"> elements). This is an exposed feature of the nsIFilePicker API, and AFAICT this bug breaks that. So the effects are more serious than "just a console message".

I don't understand why this wasn't noticed before, though - from looking at the hg blame this code seems to have been unchanged for a relatively long time.

Comment 12

[André Reinald]

Attachment: Update deprecated API calls in NS{Open|Save}Panel, convert paths to URIs

The code seems to date back before hg, and I don't yet know how to dig that far, so I ask Josh for a review. But if someone else is better qualified for this bit of code, please proceed.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

FWIW you can find pre-hg blame using bonsai:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/cocoa/nsFilePicker.mm&rev=1.23

Comment 14

[André Reinald]

Thanks Gavin, I've bookmarked the link. It seems Josh is indeed the right guy to ask for review of this patch.

Comment 15

[Josh Aas]

Comment on attachment 738092 [details] [diff] [review]
Update deprecated API calls in NS{Open|Save}Panel, convert paths to URIs

Looks good to me, nice fix!

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/43987922a6b3

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/43987922a6b3

Comment 18

[Rob Campbell [:rc] (:robcee)]

this change broke a good many save dialogs in browser.

See: bug 865803 for details. We may need review for a fix.