Go to the above URL (make sure there's no trailing URL when you type it in), and then click on one of the links at the top of the page that point to a destination anchor in the current document For example, one of these links: "Specs", "CSS Browsers", or "Authoring Tools". Notice that we don't jump to the destination anchor. Now put a trailing '/' on the above URL and reload the page. Then click on the same link and notice that we do jump to the destination anchor This is because when comparing the two URLs using Equals(), one of them has a '/' in its "mFile" data member and one doesn't I think they should be considered the same regardless of whether they both have (or have not) a trailing '/' I don't know whether this is a problem with the code that parses the URL spec, i.e. whether all URL specs should be normalized to have a trailing '/', or whether the problem is in Equals()

setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

The famous trailing slash bug. Webshell was fixed by nisheeth.

*** Bug 3143 has been marked as a duplicate of this bug. ***

Marking till Necko lands...

The behavior Troy described with the anchors seems fixed. However, relative links are no longer resolving correctly in pages redirected to add a "/" to the end. They work on other redirects (both 301 and 302; "/" redirects are always 301 from the servers I know). This stopped working between 99-03-12 and 99-03- 23, and at the same time troy's problem got better. This breakage would fix troy's problem (it seems like a hack to fix it). Examples of 301 redirects to add a slash: http://www.fas.harvard.edu/~dbaron http://www.w3.org/Style/CSS (has anchors to test) Examples of other 301 redirects: http://www.w3.org/pub/WWW/ Examples of other 302 redirects: http://www.fas.harvard.edu/~dbaron/bugpages/

*** Bug 4062 has been marked as a duplicate of this bug. ***

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

Unless I misunderstand the original comment greatly, I think the code is doing the right thing. http://www.mozilla.org/search and http://www.mozilla.org/search/ might be completely different things (and are!). Does the URL spec really say that they should be equivalent?

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or early M9. We will need to get on this and it cannot be postponed past the M9 milestone.

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

This should be fixed now. Pl. verify.

When verifying this bug, please make sure that the following URLs behave correctly as well: http://www.mozilla.org/search should give you a message about "The search system is not available.", and http://www.mozilla.org/search/ should give you a 404 not found. Thanks.

need to wait til 10627 is fixed before this can be verified

I dont think this is related to 10627.

No, it's not really related but I'm not able to access the URL indicated above as I get the 'download file' dialogue similar to 10627. I assume when that is fixed, I will be able to access it, and then verify this bug.

everything reported in this bug has been verified fixed

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.