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)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
People
(Reporter: desale, Assigned: caillon)
References
Details
(Keywords: regression, testcase, Whiteboard: [PDT-])
Attachments
(1 file)
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
HTML DOM 0 == M11/P2
Updated•25 years ago
|
Target Milestone: M11 → M12
Comment 4•25 years ago
|
||
Moving to M12. Moving testcase from description to attachment.
Comment 6•25 years ago
|
||
Moving off M12 radar for the time being. One or more might get back once I get a chance to really look at them.
Comment 7•25 years ago
|
||
In an attempt to get my bug list in order again, marking all the bugs I have currently as ASSIGNED.
Updated•25 years ago
|
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]
Comment 8•25 years ago
|
||
Moved [TESTCASE] code to Status Whiteboard field where it always should be. Thanks desale for providing it!
Comment 9•25 years ago
|
||
Updated•25 years ago
|
Target Milestone: M13 → M14
Comment 10•25 years ago
|
||
Moving this another milestone forward.
Comment 11•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Reporter | ||
Comment 14•25 years ago
|
||
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.
Comment 15•25 years ago
|
||
PDT+ for getting Link.search working, per comments above. After that, this bug will probably fall to PDT-. Thx for the comments.
Whiteboard: [PDT+]
Comment 16•25 years ago
|
||
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.
Reporter | ||
Comment 17•25 years ago
|
||
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.
Reporter | ||
Comment 18•25 years ago
|
||
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.
Comment 19•25 years ago
|
||
Removing PDT+ so pdt can be made aware that it can be moved to pdt- and approved as such.
Whiteboard: [PDT+]
Comment 21•25 years ago
|
||
Have fix in my tree. Will be checked in for M15.
Whiteboard: [PDT-] → [PDT-][HAVE FIX]
Target Milestone: M14 → M15
Comment 22•24 years ago
|
||
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-]
Reporter | ||
Comment 23•24 years ago
|
||
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.
Comment 24•24 years ago
|
||
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.
Reporter | ||
Comment 25•24 years ago
|
||
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.
Comment 26•24 years ago
|
||
jst: what functions are you calling in necko? and where is this piece of code... that I may look?
Comment 27•24 years ago
|
||
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).
Comment 28•24 years ago
|
||
oh... just use GetFilePath which stops at any of the chars in "#;?" back to you...
Assignee: gagan → jst
Comment 29•24 years ago
|
||
Done. Marking FIXED.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 31•24 years ago
|
||
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.
Comment 32•24 years ago
|
||
Also http://mozilla.org/quality/ngdriver/suites/javascript/are008.html May be related to Bug 41367, which is the inverse problem.
Comment 33•24 years ago
|
||
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.
Comment 34•24 years ago
|
||
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
Reporter | ||
Comment 35•24 years ago
|
||
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.
Comment 36•22 years ago
|
||
I'm seeing this bug in Mozilla 1.1beta. http://mozilla.org/quality/ngdriver/suites/javascript/are008.html
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 37•22 years ago
|
||
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
Comment 38•22 years ago
|
||
*** Bug 185303 has been marked as a duplicate of this bug. ***
Comment 39•22 years ago
|
||
*** Bug 185304 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Blocks: MyFirstBug
Updated•22 years ago
|
Target Milestone: M15 → ---
Comment 40•21 years ago
|
||
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)
Assignee | ||
Comment 41•21 years ago
|
||
No, they should be fixed.
Assignee | ||
Comment 42•21 years ago
|
||
Taking this bug. I'll fix the testcases.
Assignee: desale → caillon
Assignee | ||
Comment 43•21 years ago
|
||
*** Bug 146788 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 44•21 years ago
|
||
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.
Comment 45•21 years ago
|
||
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.
Assignee | ||
Comment 46•21 years ago
|
||
Go ahead and file a new bug for that then, if there isn't one already filed.
Comment 47•21 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•