Open
Bug 124873
Opened 23 years ago
Updated 2 years ago
[FIX]Linux File Picker has an extra "/" at start of file path
Categories
(Firefox :: File Handling, defect, P3)
Tracking
()
NEW
People
(Reporter: mikeypotter, Unassigned)
References
Details
Attachments
(2 files)
(deleted),
patch
|
brendan
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
Reporter: Please always specify which "Build ID" you're using,
as found in the title bar of the main Mozilla window.
Comment 2•23 years ago
|
||
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
Comment 3•23 years ago
|
||
This should do it...
Comment 4•23 years ago
|
||
Pete, would you review?
Comment 5•23 years ago
|
||
(From attachment 68982 [details] [diff] [review])
r=pete
Comment 6•23 years ago
|
||
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+
Comment 7•23 years ago
|
||
Good question. Pete?
Patch checked in, but leaving bug open for now for the trailing slash issue.
Comment 8•23 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
Comment 10•23 years ago
|
||
how's this?
Comment 11•23 years ago
|
||
From my manual page of strlen:
size_t strlen(const char *s);
--> it returns size_t, not ssize_t.
Comment 12•23 years ago
|
||
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....
Comment 13•23 years ago
|
||
> 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.
Comment 15•23 years ago
|
||
I am no longer seeing this, is anybody else?
Comment 16•23 years ago
|
||
Christian, see comment #7, this has been checked in.
Updated•22 years ago
|
QA Contact: sairuh → petersen
Updated•22 years ago
|
Target Milestone: mozilla0.9.9 → ---
Updated•15 years ago
|
QA Contact: chrispetersen → file-handling
Updated•8 years ago
|
Product: Core → Firefox
Version: Trunk → unspecified
Comment 17•6 years ago
|
||
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Comment 18•6 years ago
|
||
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Comment 19•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: pete → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•