[FIX]Linux File Picker has an extra "/" at start of file path

NEW

Status

()

Firefox
File Handling
P2
normal
16 years ago
a year ago

People

(Reporter: Mike Potter, Assigned: Pete Collins (MDG))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
In my file picker, paths to files have an extra "/" at the start of them.  For
eg. they show up as "//home/mikep" instead of "/home/mikep".
Sorry if this isn't in the right component, I don't know where it should go.

Comment 1

16 years ago
Reporter: Please always specify which "Build ID" you're using,
as found in the title bar of the main Mozilla window.
I'm seeing this with tip from this morning and every build as far back as I've
been working onfilepicker (a month? more?).  I'm almost certain this is an
nsLocalFileUnix problem.

I'll take this and investigate....
Assignee: law → bzbarsky
Created attachment 68982 [details] [diff] [review]
Patch

This should do it...
Pete, would you review?
Keywords: patch, review
Priority: -- → P2
Summary: Linux File Picker has an extra "/" at start of file path → [FIX]Linux File Picker has an extra "/" at start of file path
Target Milestone: --- → mozilla0.9.9
(Assignee)

Comment 5

16 years ago
(From attachment 68982 [details] [diff] [review]) 
r=pete

Comment on attachment 68982 [details] [diff] [review]
Patch

Looks ok, but I wonder why we don't strip trailing slashes from fragment too.

/be
Attachment #68982 - Flags: superreview+
Good question.  Pete?

Patch checked in, but leaving bug open for now for the trailing slash issue.
(Assignee)

Comment 8

16 years ago
Agree, the trailing slash issue is rather annoying.

I can do it, if you want to do it, that's cool too . . .

--pete
*** Bug 84760 has been marked as a duplicate of this bug. ***
Created attachment 69135 [details] [diff] [review]
kill extra slashes

how's this?
From my manual page of strlen:
       size_t strlen(const char *s);

--> it returns size_t, not ssize_t.
ssize_t is the signed version, so size_t can just be cast over to it for not too
big values of size_t.  I just copied that part of the code from InitWithPath,
but now that I look at it there seems to be no reason to use ssize_t here _or_
there.  Or in Contains() for that matter....  
> for not too big values

Yes, that's it. If there's no reason to use the limited datatype, why use it?
Maybe use size_t in all mentioned functions.
no more time to work on this...
Assignee: bzbarsky → petejc
I am no longer seeing this, is anybody else?

Comment 16

16 years ago
Christian, see comment #7, this has been checked in.
QA Contact: sairuh → petersen
Target Milestone: mozilla0.9.9 → ---
QA Contact: chrispetersen → file-handling

Updated

a year ago
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.