22961 - [PP] Mac: select local file uses colons instead of slashes for path

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[pmock]

Build Date & Platform Bug Found:
 MacOS commercial seamonkey build 2000-01-03-08-m13 installed on G3/400 OS 8.6

Overview Description:
 When I use the 'select file' dialog to choose a local file, it uses colons
instead of slashes in the url. This causes the start page not to load.  No error
message. The naviator page is blank.  The messenger pane is blank and the
folders list does not display.

* This occurs using the "select file" button to change the default navigator web
page or messenger start page.

Steps to Reproduce:
1) Launch Seamonkey
   The browser page opens.
2) Select the Edit|Preference
3) Highlight the "mail and newsgroup" category
4) Under the Messenger start page section, click on the "select file" dialog
5) Choose a html file on your local drive
6) Press OK
   The dialog is dismissed and the url is displayed in the location field.
Example:
  hard drive:desktop folder:junk:test.html

Actual Results:
 It uses colons as the delimiter instead of slashes.  The start page fails to
load.  No error message.

Expected Results:
 It should uses slashes in the url.

Additional Builds and Platforms Tested On:
 This problem does occur on Mac commercial seamonkey build 2000-01-02-08-m13.
 This problem does not occur on win32 or linux commercial seamonkey build
2000-01-02-09-m13.

Additional Information:
 This bug was found loading bug 22955.  I did not want to combine these bug
since it only a Mac [PP] issue.

 This problem does not occur in Page Composer when I insert a image in a web
page.

Comment 1

[Jean-Francois Ducarroz]

You are right, we should convert the nsFileSpec to an URL.

Comment 2

[(not reading, please use [e-mail] instead)]

re-assign to sdagley, cc dougt and warren.

they are the nsIFile guys.

Comment 3

[Steve Dagley]

Setting to M14 since it isn't a blocker

Comment 4

[Steve Dagley]

This also occurs in the open file dialog so obviously there are several places in 
the code that are assuming they're getting a Win or Unix path and failing 
miserably when presented with a Mac path.  How surprising. :-(  We really need to 
fix this before beta1

Comment 5

[rickg]

We need this for beta.

Comment 6

[Mike Pinkerton (not reading bugmail)]

per dagley's instructions, moving to dougt else this won't get fixed for beta.

Comment 7

[Doug Turner (:dougt)]

This is a bug in the preferences code.  It looks like the functions are doing 
the wrong thing:

http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/con﷒0﷓

this explictly uses the nativePath of the filespec, not the URL.  This will give 
you colons on the mac.

http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/con﷒1﷓

returns the native path as a string.  maybe this should return a nsFileSpec, and 
have the caller convert it to a URL.

Assign this to the author.  I may be overlooking something.

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

you want to display a native path in the text field. user prefs.js should always 
store nativePaths. the person reading the pref from the back end should create a 
fileSpec, assign the pref's string value to the nativePath attribute of the 
fileSpec, and retrieve the actual filename from there. Displaying a garbled file 
path in the prefs UI is NOT a good thing to do and is not consistent with what 
current UI does. If I'm on Mac, and I select Mac HD:foo:bar.html as my homepage, 
thats what it should appear as in the text field, similarly on windows, I should 
see c:\foo\bar.html, not file:///c|\foo\bar.html or whatever. 

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

also, PrefsWindow.js is no longer used. It should probably be removed frmo the 
repository, btu no one has got around to doing it yet :) 

Comment 10

[Doug Turner (:dougt)]

Where does the conversion from this native string turn into a URL for the 
actual page load?

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

in the mailnews code, the start page url is simply read and loaded.

if (startpageenabled)
  startpage = pref.CopyCharPref("mailnews.start_page.url");
window.frames["messagepane"].location = startpage;

oh shit. 

*hacks*

Comment 12

[Doug Turner (:dougt)]

This is why we should use the cross platform canonical string: the URL.  
(assuming that the mac will encode the volume number)

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

but we cant do that for display

the issue here is: when we go to read the prefs, we could find values like:

http://www.mozilla.org/

fine, we can just display that in the text field

or, file:///c|/foo/bar/nerf.html

which we should not display in the field, as it looks awful. We should display 
c:\foo\bar\nerf.html or Mac HD:Foo:Bar:Nerf.html. How do we tell whether or not 
we have a file and should display as such? do we just parse off the "file:"? 
that seems hacky. 

Comment 14

[Doug Turner (:dougt)]

So, store the value as a URL, and if it is a file url, display it as a native 
path.  

Comment 15

[Doug Turner (:dougt)]

Yeah, since you are not using nsIFile, you will have to just check to see if the 
first chars are "file:", and if so convert to a native filepath.

I would suggest that you convert to using nsIFile and use Necko for the URL 
parsing.

Comment 16

[Warren Harris]

I disagree with this whole discussion. Users should never see native paths, 
only file: URLs. Why? Because there is no such thing as a native path to a mac 
user (unless you're an MPW user).

Comment 17

[Ben Goodger (use ben at mozilla dot org for email)]

I think I've checked in an interim hack for this,

now we just display the file URL of the file picked from the file picker. This 
should now be read properly and loaded everywhere. 

Comment 18

[fenella]

Mac (2000-02-23-12 M14)
The bug is fixed. The selected local file uses slashes for path.
It also loads the selected file. However, it came up briefly before the Password
dialog comes up. I shall write a separate bug.

Comment 19

[fenella]

Forgot to mention that Peter is on sabatical. That is why I am verifying his
bug.