This has nothing to do with JS engine.
Assignee: general → darin
QA Contact: pschwartau → benc
Further, this is invalid. Everything after the '#' is part of the fragment identifier. If both a fragment identifier and a query are present, the query must come first. The fragment identifier is not even part of the URI proper, while the query most definitely is. See RFC 2396 <http://web.mit.edu/rfc/rfc2396.txt>. In other words, when you were doing: http://localhost/cams/reload.htm#abookmark?http%3A//localhost/test.html you should have been doing: http://localhost/cams/reload.htm?http%3A//localhost/test.html#abookmark
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
V/dupe: you can see some related examples about the trickiness of the URL reserved characters and their order in: http://www.ics.uci.edu/%7Efielding/url/test1.html
Status: RESOLVED → VERIFIED
Summary: window.location.search not filled when bookmark and query is given → window.location.search vs. "#" (anchor)
Summary: window.location.search vs. "#" (anchor) → URL: window.location.search vs. window.location.hash
OK, thx for info and sorry for posting it, but I remember that I had to use a "#?" construct to get the script to work on a browser. So after lots of experimenting i assumed #? is the correct order. I agree with you that the rfc states bookmark after query. Maybe you can think of being tolarant to that misordering .. but i will change my script. I'm surprised not facing that pb because i'm calling .htm with #? since 2 years or more.
> Maybe you can think of being tolarant to that misordering How, exactly? You can have a '?' char in a fragment identifier...
bz: communicator would allow "?" after a fragment to be a query. This was wrong, but we actually had netscape.com pages for Netscape 6 that were supposed to use links like this, which were broken b/c Netscape 6 parsed them correctly and went to the wrong anchor on the page. (someone at AOL was probably writing pages for the site using Communicator for viewing).
> bz: communicator would allow "?" after a fragment to be a query. Yes, I realize that. It had a lot of other bugs too....
I would say ? is possible in fragment only in %3f encoding if the order #..? is used. I think its very unlikely to have an '?' in a query maybe #a?b#c expands to fragment #a and query #a?b#c. I would apply these regular expressions (it's simplified of course), depending on the first character: \?[^#]*(#.*)? #[^\?]*(\?.*)? in other words: - when fragment comes first, it may not contain a ? which starts a query (the query may contain unescaped #). - when query comes first, it may not contain a # which starts the fragment (the fragment may contain unescaped ?) I wonder wether #text? is used in the field or wether it's just "#?" without a real fragment. In my personal opinion the rfc aren't good at this point of definition, because # is not a reserved character. If it were, we wouldn't have that problem. How's about setting window.location.search = "?http%3A//localhost/test.html" window.location.hash = "#abookmark?http%3A//localhost/test.html" for http://localhost/cams/reload.htm#abookmark?http%3A//localhost/test.html I don't like it much but maybe thats a possible way. But in this case when focusing the fragment it would be intelligent to jump to the fragment "#abookmark?http%3A//localhost/test.html" if present, and if not present jump to "#abookmark".
> because # is not a reserved character. Sure it is. See section 2.4.3 of the RFC. An unescaped '#' is allowed in a URI ONLY if it marks the beginning of the fragment identifier.
Unless you mean "reserved" in the sense the RFC uses it. '#' is stronger than that -- it's a "delim", which means that it's not allowed as part of URIs at all (technically the fragment identifier is not part of the URI proper), unlike '?' which is allowed to delimit the query. So once you have hit a '#' you know you have reached the end of the URI and the rest of what follows is part of the fragment identifier, not part of the URI itself.
You need to log in before you can comment on or make changes to this bug.