If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Assigning a string to a .pathname property result only into a partial string

VERIFIED FIXED in mozilla1.0

Status

()

Core
DOM: Core & HTML
VERIFIED FIXED
16 years ago
6 years ago

People

(Reporter: Andrea, Assigned: jst)

Tracking

({regression, testcase})

Trunk
mozilla1.0
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [FIXED ON TRUNK], URL)

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
Changing a link URL, reasigning its .pathname property results
into a partial assignation of the new path string.

Tested on 1.0.0 RC1

Looking at the above address, will display 2 frames.
Look how the parent document JS will truncate the below frame
links addresses. Viewing just the frame below will show how
the links URLs should look.
(Reporter)

Comment 1

16 years ago
Created attachment 81240 [details]
A reduced and commented testcase
Keywords: testcase

Comment 2

16 years ago
Browser, not engine ---> DOM Level 0.

Confirming bug on WinNT using Mozilla trunk binary 20020422xx.
There's something really strange going on here.


Examples from the JS Debugger:


document.links[0].pathname = "/second/fictuos_path.html";
document.links[0].pathname
[string] "/second/fict." <<<------------- ??? LOOK AT THIS TRUNCATION !!!


document.links[0].pathname = "/aaaaaaaaaa/bbbbbbbbbb/cccccccccc";
document.links[0].pathname
[string] "/aaaaaaaaaa/bbbbbbbbbb/" <<<------------ ANOTHER TRUNCATION !!!


document.links[0].pathname = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
document.links[0].pathname
[string] "/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"  <<<------ WHY A LEADING SLASH???
Assignee: rogerl → jst
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → desale
(Assignee)

Comment 3

16 years ago
This is a bug in the URL parsing code, cc:ing darin and rpotts. Patch coming up.
Status: NEW → ASSIGNED
Keywords: mozilla1.0, nsbeta1, regression
OS: Windows 98 → All
Hardware: PC → All
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 4

16 years ago
Created attachment 81292 [details] [diff] [review]
Fix the offset calculations in the URL parsing code...

darin and rpotts, r= and sr= please?

Comment 5

16 years ago
Comment on attachment 81292 [details] [diff] [review]
Fix the offset calculations in the URL parsing code...

sr=darin (nice catch!)
Attachment #81292 - Flags: superreview+
Need r= fast and trunk landing to get this into 1.0.

/be
Blocks: 138000
Comment on attachment 81292 [details] [diff] [review]
Fix the offset calculations in the URL parsing code...

r=bbaetz, but:

>Index: netwerk/base/src/nsStandardURL.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/netwerk/base/src/nsStandardURL.cpp,v
>retrieving revision 1.21
>diff -u -r1.21 nsStandardURL.cpp
>--- netwerk/base/src/nsStandardURL.cpp	11 Apr 2002 22:52:53 -0000	1.21
>+++ netwerk/base/src/nsStandardURL.cpp	27 Apr 2002 16:32:40 -0000
>@@ -1854,12 +1854,12 @@
>             encoder.EncodeSegment(Substring(filepath + dirPos, filepath + dirLen),
>                                   esc_Directory|esc_AlwaysCopy, spec);

Doesn't this one need +dirPos, too?
Attachment #81292 - Flags: review+
(Assignee)

Comment 8

16 years ago
Created attachment 82654 [details] [diff] [review]
Same as above but includes bbaetz's suggestion and some more cleanup for readability.
(Assignee)

Comment 9

16 years ago
Comment on attachment 82654 [details] [diff] [review]
Same as above but includes bbaetz's suggestion and some more cleanup for readability.

Moving r=bbatez forward.
Attachment #82654 - Flags: review+

Comment 10

16 years ago
Comment on attachment 82654 [details] [diff] [review]
Same as above but includes bbaetz's suggestion and some more cleanup for readability.

sr=darin
Attachment #82654 - Flags: superreview+
(Assignee)

Comment 11

16 years ago
Fix checked in on trunk, requesting permission to fix on the branch as well...
Whiteboard: [HAVE FIX] → [FIXED ON TRUNK]

Comment 12

16 years ago
Comment on attachment 82654 [details] [diff] [review]
Same as above but includes bbaetz's suggestion and some more cleanup for readability.

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #82654 - Flags: approval+
(Assignee)

Updated

16 years ago
Keywords: mozilla1.0, nsbeta1 → adt1.0.0, mozilla1.0+, nsbeta1+
(Assignee)

Comment 13

16 years ago
Fixed on branch and trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED

Comment 14

16 years ago
Verified on trunk with 2002-05-21-08-trunk.
Status: RESOLVED → VERIFIED

Comment 15

16 years ago
verified1.0.0
Keywords: verified1.0.0

Comment 16

16 years ago
posthumus adt1.0.0+, pls get ADT approval prior to checking in to the 1.0 branch.
Keywords: adt1.0.0 → adt1.0.0+
You need to log in before you can comment on or make changes to this bug.