41367 - hash, and pathname are returning wrong strings from Link Object.

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Prashant Desale]

hash, and pathname are returning wrong strings from Link Object. link.hash 
returns hash + search. Link.pathname returns pathname + hash + search.


BUILDS: 2000-06-02-08.

STEPS TO REPRODUCE:
1] Load the testcase I'm going to attach.
2] Compare expected results and actual results on the page. [After loading 
testcase, you'll see actual results, and expected results.

EXPECTED RESULTS:
Link.hash should return only hash and not hash + search.
[It should return "#angels" in case of testcase provided.]
Link.pathname should only return only path portion of URL, and not pathname + 
hash + search.
[It should return "/docs/index.html" in case of testcase provided.]

ACTUAL RESULTS:
Link.hash returns hash + search. 
[It returns "#angels?ser=15" in case of testcase]
Link.pathname name returns pathname + hash + search.
[It returns "/docs/index.html#angels?ser=15" in case of testcase]

Comment 1

[Prashant Desale]

Attachment: Testcase attached.

Comment 2

[Johnny Stenback (:jst)]

Accepting, should be easy to fix, and this is needed for backwards compatibility

nominating for nsbeta2.

Comment 3

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 4

[Johnny Stenback (:jst)]

The URL in the testcase (http://www.yahoo.com/docs/index.html#angels?ser=15)
is invalid, the search part (the part after the '?') must be before the ref
(the part after the '#'), the ref can legally contain '?'. The url does work
in 4.x but it's clearly not a valid URL (according to the Necko guys).

Comment 5

[Prashant Desale]

Yes Johnny the URL in testcase is not valid [I mean working] because it is 
something I came up with for example.
If ref can legally contain '?' then why it is returning 
1] First Link hash = #angels in 4.x ?
Either implimentation in 4.x is wrong or there is problem with our build. 
Results in both browsers should match right ?
And about pathname, there is a problem. 

Anyway necko people surely know more about this. I just wanted to let you know 
that there is difference in results on 4.x and on seamonkey.
In that case we could live with link.hash. We only need to correct 
link.pathname.
What do you think ?

Comment 6

[Johnny Stenback (:jst)]

desale, I think the reason it works in 4.x is a bug in 4.x, here's the reply I
got to the mail I sent to [e-mail] (mozillas URL parser
god) and [e-mail]: 

---
Hi Johnny! 

Johnny Stenback wrote: 

  Hello guys, 

  I'm working on a nsbeta2+ DOM bug that deals with accessing different 
  parts of URL's through the DOM HTMLAreaElement interface (and others) 
  and I ran across this problem and it looks like this is something that 
  needs to be solved in necko. 

  The problems is that I have the following URL: 

    http://www.yahoo.com/docs/index.html#angels?ser=15 

  and asking for the ref (nsIURL::GetRef()) on that URL returns 
  "angels?ser=15", and not just "angels", and I did a quick test with 
  GetQuery() and that returns an empty string and not "ser=15". 

  Am I correct in thinking this is a necko bug (all the above work in NS 
  4.x), should I fix the DOM part of the bug 
  (http://bugzilla.mozilla.org/show_bug.cgi?id=41367) and reassign to one 
  of you guys? 

  Thanks! 

  -- 
  jst

This is not a necko bug, this a broken URL. It is clearly defined in RFC 2396
that the query part comes before the ref, everything after the last # is the
ref, it may of course contain a ?.  Parsing is okay, the URL is broken. 

Andreas
---

I didn't check what RFC 2396 says, but I do trust Andreas. If this becomes a
real problem in mozilla we might need to solve it either in necko or in the DOM
code, but until then I'd suggest we leave .hash as is.

I checked in the fix for the .pathname problem, marking this fixed.

Comment 7

[Prashant Desale]

Yeah, in that case we should leave hash part.
I'll verify first thing in next build.
COOL.

Comment 8

[Prashant Desale]

Verified with 2000-07-05-09.

Comment 9

[Bob Kanefsky]

Test case
   http://mozilla.org/quality/ngdriver/suites/javascript/are001.html
is failing in M18 build 2000080120 under MacOS 8.6.
The "Actual Result" column shows the search strings.

Comment 10

[Bob Kanefsky]

Marking as regression and reopening.  Based on the comments, it may have broken 

again sometime in July.  Attachment tested in 2000072920/MacOS9.0, matrix test 

suite in 2000080120/MacOS8.6 above; both fail.

Comment 11

[Johnny Stenback (:jst)]

The testcase is incorrect, using URL's with "...#whatever?foo" is invalid if you
expect "?foo" to be the search string, read my comment from 2000-06-13 18:42.
Marking FIXED again.

Comment 12

[Jim Roskind]

Based on the above comment, the testcase has an invalid component.
I verified that the "pathname" element of the attached test case works on Win NT.
Probably still needs test/verification on other platforms.

Comment 13

[Jim Roskind]

I should have been more explicit about my verification:
I verified using build 2000080204 on Win NT.  This is a beta2 M17 branch build.

Comment 14

[Prashant Desale]

Johnney is correct. Me and Johnney had talk over this last time I verified this 
one. Testcase I prvided is not really accurate since hash could contain "?" in 
the string. 
As fas as pathname is concerned, I verified it with 2000-08-03-04 on win-95, and 
also automation on Linux does not show there is any problem with pathname.

If we compare the results in 4.x and seamonkey then yes, there is difference in 
return value of link.hash because, I believe its a bug in 4.x itself.

Marking it verified.