Closed
Bug 114125
Opened 23 years ago
Closed 23 years ago
nsStandardURL::Clone fails to clone the nsIFile if one exists
Categories
(Core :: Networking, defect, P2)
Core
Networking
Tracking
()
VERIFIED
FIXED
mozilla0.9.9
People
(Reporter: sfraser_bugs, Assigned: darin.moz)
Details
Attachments
(1 file, 1 obsolete file)
1.52 KB,
patch
|
dougt
:
review+
sfraser_bugs
:
superreview+
|
Details | Diff | Splinter Review |
nsStandardURL::Clone() doesn't clone its nsIFile into the cloned spec. This
causes code later to have to re-create the nsIFile, which (on Mac at leaast)
involves a full path to FSSpec conversion, which is expensive.
Reporter | ||
Comment 1•23 years ago
|
||
Assignee | ||
Comment 2•23 years ago
|
||
actually, i think calling nsIFile::clone is unnecessary... this should be ok:
Index: nsStandardURL.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/base/src/nsStandardURL.cpp,v
retrieving revision 1.5
diff -u -r1.5 nsStandardURL.cpp
--- nsStandardURL.cpp 5 Dec 2001 23:54:55 -0000 1.5
+++ nsStandardURL.cpp 8 Dec 2001 00:44:43 -0000
@@ -1138,6 +1138,7 @@
clone->mQuery = mQuery;
clone->mRef = mRef;
clone->mParser = mParser;
+ clone->mFile = mFile;
NS_ADDREF(*result = clone);
return NS_OK;
because, mFile is cached only to improve the cost of GetFile. the resulting
mFile is never modified... it is only released.
Reporter | ||
Comment 3•23 years ago
|
||
But nsStandardURL doesn't own the file that's passed to SetFile(); it just
AddRefs it. So the caller could call SetFile(), then modify the nsIFile. If
Clone() didn't clone the nsIFile, then someone could change the nsIFile for more
than on nsIURI. Yuck.
Assignee | ||
Comment 4•23 years ago
|
||
in that case, nsStandardURL::SetFile is wrong. it should clone the nsIFile if
it is going to hold onto it. in the current world the caller of SetFile could
modify the nsIFile and nsStandardURL would still happily give out the modified
nsIFile via nsStandardURL::GetFile. so, if the clone belongs anywhere it
belongs in SetFile :(
Assignee | ||
Comment 6•23 years ago
|
||
-> 0.9.9
Severity: normal → major
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.9
Assignee | ||
Comment 7•23 years ago
|
||
simon: how about this patch? can you sr=?
Attachment #60887 -
Attachment is obsolete: true
Comment 8•23 years ago
|
||
Comment on attachment 66951 [details] [diff] [review]
v2: clone in SetFile
add a ns_warning if the clone fails.
Attachment #66951 -
Flags: review+
Reporter | ||
Comment 9•23 years ago
|
||
Comment on attachment 66951 [details] [diff] [review]
v2: clone in SetFile
sr=sfraser
Attachment #66951 -
Flags: superreview+
Assignee | ||
Comment 10•23 years ago
|
||
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•