Closed Bug 12559 Opened 25 years ago Closed 21 years ago

basedLink.pathname, Link.port, Link.protocol, and Link.search return undefined.

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: desale, Assigned: caillon)

References

Details

(Keywords: regression, testcase, Whiteboard: [PDT-])

Attachments

(1 file)

TESTCASE copied from inline HTML
1.14 KB, text/html
Details 
Link.pathname, Link.port, Link.protocol, and Link.search return undefined
instead of returning pathname, port, protocol, and search part of URL

BUILDS:
08-24-13 [M9] [Apprunner/Viewer]
08-24-09 [M10] [Apprunner/Viewer]

STEPS TO REPRODECE:

1] Please copy HTML code I'm providing. Save it as HTML file.
2] Open this file with Apprunner/Viewer.
3] You'll see one button called
"Check pathname, port, protocol, search for Link".
4] Click this button.

EXPECTED RESULTS:
Link.pathname :/index.html
Link.port :Port [Communication port that server uses].
Link.protocol :http:
Link.search :?ser=10

ACTUAL RESULTS:
Link.pathname :undefined
Link.port :undefined
Link.protocol :undefined
Link.search :undefined

CODE:

<HTML>
<HEAD>
<TITLE>Link Test</TITLE>
</HEAD>
<SCRIPT>
<!--
function linkprop(){
document.workform.result.value=document.links[0].pathname;
document.workform.result1.value=document.links[0].port;
document.workform.result2.value=document.links[0].protocol;
document.workform.result3.value=document.links[0].search;
}
//-->
</SCRIPT>
<BODY>
<FORM NAME="workform">
<A HREF="http://www.netscape.com/index.html?ser=10">Test Link:
http://www.netscape.com/index.html?ser=10</A><BR>
Link.pathname:<INPUT TYPE="text" SIZE="30" NAME="result" VALUE=""><BR>
Link.port    :<INPUT TYPE="text" SIZE="30" NAME="result1" VALUE=""><BR>
Link.protocol:<INPUT TYPE="text" SIZE="30" NAME="result2" VALUE=""><BR>
Link.search  :<INPUT TYPE="text" SIZE="30" NAME="result3" VALUE=""><BR>
<INPUT TYPE="button" NAME="but1" VALUE="Check pathname, port, protocol, search
for Link" onClick="linkprop();">
<INPUT TYPE="reset" NAME="res1" VALUE="Reset"><BR><BR>
<H3>Expected Answers:<BR></H3>
Link.pathname    :/index.html<BR>
Link.port        :Communication port that server uses.<BR>
Link.protocol    :http:<BR>
Link.search      :?ser=10<BR>

</FORM>
</BODY>
</HTML>

END OF CODE:
*** Bug 12543 has been marked as a duplicate of this bug. ***
*** Bug 12545 has been marked as a duplicate of this bug. ***
Priority: P3 → P2
Summary: Link.pathname, Link.port, Link.protocol, and Link.search return undefined. → [TESTCASE] Link.pathname, Link.port, Link.protocol, and Link.search return undefined.
Target Milestone: M11
Target Milestone: M11 → M12
Moving to M12. Moving testcase from description to attachment.
*** Bug 15053 has been marked as a duplicate of this bug. ***
Moving off M12 radar for the time being. One or more might get back once I get a
chance to really look at them.
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
Summary: [TESTCASE] Link.pathname, Link.port, Link.protocol, and Link.search return undefined. → Link.pathname, Link.port, Link.protocol, and Link.search return undefined.
Whiteboard: [TESTCASE]
Moved [TESTCASE] code to Status Whiteboard field where it always should be.
Thanks desale for providing it!
Target Milestone: M13 → M14
Moving this another milestone forward.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Setting priority to major.
Severity: normal → major
Keywords: beta1
vidur, can you comment on severity please?
Whiteboard: [TESTCASE]
Vidur, don't you think link.search is important to lot of web-developers ?
I mean forget about other properties like pathname, protocol and stuff, but 
link.search is surely important and thats what makes this bug important too.
PDT+ for getting Link.search working, per comments above.  After that, this bug 
will probably fall to PDT-.  Thx for the comments.
Whiteboard: [PDT+]
Is it that important? Link.search just returns the value after the ? in the link 
URL. I'll fix it if it's that much of a concern, but I'm not aware that it is.
Vidur, If you think its not that important then we can go for this one, PDT+ or 
PDT-. I was just thinking that, some people might maintain some flags or 
something like that on their server scripts, depending on what link.search 
returns. Or may be link.search might be used to change values of session 
variables. 
But I think your guess would always be better than mine, so if you think its not 
important then, we could go for PDT, and not the beta1 blocker.
I just taled to vidur about this one, and according to our discussion, there are 
some people who use it, but it does not seem like to be as important to be 
marked as beta1 blocker or PDT+. So I guess we can fall this bug on PDT- too.

Removing PDT+ so pdt can be made aware that it can be moved to pdt- and approved 
as such.
Whiteboard: [PDT+]
Marking pdt- based on vidur's comments.
Whiteboard: [PDT-]
Have fix in my tree. Will be checked in for M15.
Whiteboard: [PDT-] → [PDT-][HAVE FIX]
Target Milestone: M14 → M15
Vidurs fix is checked in but from looking at the testcase I think there might
still be problems with this. Check the testcase, the pathname doesn't match the
expected answer. From looking at the code I think that the remaining part of
this bug is in necko, assuming that the testcase is correct.

Over to the network gurus, they'll know what's right here.
Assignee: vidur → gagan
Status: ASSIGNED → NEW
Whiteboard: [PDT-][HAVE FIX] → [PDT-]
I provided the above testcase and I reviewed it again today to make sure 
everything is correct. Testcase is correct and Expected answer for 
pathname is "/index.html" which is correct. If its returning some other value 
then there is something wrong. Path name is nothing but a URL-path portion of 
the URL, which is "/index.html" in above testcase.

Pathname currently returns "/index.html?ser=10" in the testcase (wich seems
wrong to me too), the dom code does a url->GetPath() and nothing more so I think
the url->GetPath() code returns too much of the url.
If pathname is returning "/index.html?ser=10" then it is surely wrong, because 
"?ser=10" is link.search value and not the part of pathname. In this case 
pathname should be just "/index.html". I think somewhere link.pathname and 
link.search are getting together and link.pathname is returning that value.
jst: what functions are you calling in necko? and where is this piece of code... 
that I may look?
I'm simply calling GetPath() on a nsIURI interface (ie nsStdURL::GetPath() in
most cases), the code is in layout/html/content/src/nsHTMLAncorElement.cpp:491,
the function is nsHTMLAnchorElement::GetPathname(nsString& aPathname).
oh... just use GetFilePath which stops at any of the chars in "#;?" back to
you...
Assignee: gagan → jst
Done. Marking FIXED.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Marking verified.
Status: RESOLVED → VERIFIED
Under 2000080104 under MacOS 8.6, QA test
  http://mozilla.org/quality/ngdriver/suites/javascript/lin008.html
reports a failure and shows a blank Actual Result.  Also,
  http://mozilla.org/quality/ngdriver/suites/javascript/lin001.html
reports a failure and shows "angels?ser=10" as actual result, and
  http://mozilla.org/quality/ngdriver/suites/javascript/lin010.html
does not display a pass/fail result.
Others pass, except lin011 (handleEvent) which is known to fail.

Perhaps this bug needs to be reopened.

Also http://mozilla.org/quality/ngdriver/suites/javascript/are008.html

May be related to Bug 41367, which is the inverse problem.
Reopening as a regression, based on test matrix results above (2000080104 under 
MacOS 8.6), and changing platform from PC to All.  (Just got the permission bit.)
Status: VERIFIED → REOPENED
Keywords: regression
Hardware: PC → All
Resolution: FIXED → ---
Summary: Link.pathname, Link.port, Link.protocol, and Link.search return undefined. → , basedLink.pathname, Link.port, Link.protocol, and Link.search return undefined.
The testcases mentioned as resons for reopening this bug are all incorrect, also
the testcase in bug 41367 (marked fixed again) is incorrect. The reason for
http://mozilla.org/quality/ngdriver/suites/javascript/lin010.html not working is
due to invalid HTML/JS useage. Marking as FIXED again, please see bug 41367 for
a better explanation to why the testcases are invalid.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Johnney is right. Marking verified.
Status: RESOLVED → VERIFIED
Summary: , basedLink.pathname, Link.port, Link.protocol, and Link.search return undefined. → basedLink.pathname, Link.port, Link.protocol, and Link.search return undefined.
I'm seeing this bug in Mozilla 1.1beta.

http://mozilla.org/quality/ngdriver/suites/javascript/are008.html
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
That testcase is broken, it expects "foo" in a "...#bar?foo" URL to be the
search string, which it's not, everything after the #, including the '?' in a
URL is the ref part of the URI...

Over to desale.
Assignee: jst → desale
Status: REOPENED → NEW
*** Bug 185303 has been marked as a duplicate of this bug. ***
*** Bug 185304 has been marked as a duplicate of this bug. ***
Blocks: MyFirstBug
Target Milestone: M15 → ---
Depends on: 146788
Is this bug still alive?
I agree with Johnny Stenback that are008.html testcase is broken, and so is
are001. URI-references as defined by RFC 2396 come after the URI and the hash
character. (see http://www.ietf.org/rfc/rfc2396.txt chapter 4).

The testcase in this bug though does not work entirely correct, namely the
Link.port is only returned when it is not 80 (81 and 8080 work fine). Is this by
specification? Is there a specification?

Shouldn't the broken testcases be removed?

(sorry 3 bugs in 1)
No, they should be fixed.
Taking this bug.  I'll fix the testcases.
Assignee: desale → caillon
No longer depends on: 146788
*** Bug 146788 has been marked as a duplicate of this bug. ***
lin001 and lin010 seem to have already been fixed.

I checked in fixes for are001, are008, and lin008.  I'm resolving this fixed. 
Please allow up to an hour for the changes to make their way onto mozilla.org.
Status: NEW → RESOLVED
Closed: 24 years ago → 21 years ago
Depends on: 146788
Resolution: --- → FIXED
I also meant to say that the testcase attached to this bug is a valid testcase.
And that mozilla doesn't display Link.port correctly.
It should display Link.port: 80, whereas it displays nothing at all (in my build
2003090204 at least). But, like I said, I'm not sure if this is a bug or by
specification. IE displays Link.port: 80, if that's to any help.

Regards, M.
Go ahead and file a new bug for that then, if there isn't one already filed.
Wasn't this the original bug? This bug seems to be reopened because of comment
#31 (the testcases). But those were broken, so that should've been a new bug report.
I am saying that the testcase in the original bug report is a valid testcase,
and that there is still a bug not fixed.
I can imagine javascript developers wanting to know the port of the server to
which a link links.

BTW. I did search for this bug, but all bugs I found were marked duplicates of
this bug.
No longer depends on: 146788
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: