To replicate the error do the following: navigate to www.microsoft.com click the 'Developer Tools' link under the 'Product Families' Heading Once the page is loaded click the 'Support' tab Once the page is loaded click the 'Search' tab --This generates the error

All yours Mr. Gecko

FWIW, following the recipe above, I don't get a crash using Feb03 & Feb10 win95 non-debug builds, BUT I did notice there is a flaw in the HTML at: http://msdn.microsoft.com/vstudio/technical/support.asp which is the penultimate page noted above. The flaw is the the HREF for the 'Search' button on that page is of a form: <A HREF=http://foo/bar/default.asp?att=value"> ....^ ....^ i.e., unbalanced quotes When I click on the link (image), the URL location text box in viewer.exe changes to: file:///http|//search.microsoft..... Perhaps this (or some variation) crashes NT (the reported Platform/OS:).

For completeness: the HREF also has a TARGET attribute <A HREF=http://foo/bar/default.asp?att=value" target="_top"> ....^ ....^

Fixed the bad html problem. In such cases, we will force quotes around the attribute value.

Good news, bad news. Reopened, but probably not your bug anymore. (netlib?) Your (rickg) fix is fine, but I (stupidly) didn't realize that the problem was *not* the unbalanced quotes (noted above). The *real* (??) problem is the presence of a backslash '\' in the HREF URL. Changing to a forward slash allows viewer.exe to proceed correctly (i.e., load the HREF). Here's the HREF: <A HREF=http://search.microsoft.com/search/default.asp?SPath=\vstudio&SName=Visual% 20Studio&Cluster=MSDN" target="_top"> A similar mishandling of backslash is in as bug #3108 (Feb 10), although this one is in the context of <FRAME SRC> not loading. (Note: On win95 viewer.exe (Feb 3, Feb 10, Feb 19), I have not had a crash as noted by the original submitter (winNT), but I do get the 'file:///http|//hostname...' URL handling as noted previously).

Sounds like a netlib problme. Assigning the bug to gagan

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Changed Component to Networking Library

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

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. ;-)

Please check with Necko.

Well, this doesn't crash anymore but it also doesn't load any content. I'm pretty sure that is a dup of a bug harish just fixed. I will marked this resolved then verify on Monday with new builds.

this is crashing on the backslash in the URL, which is a dup of 3108, re-opening quickly to mark as suck

*** This bug has been marked as a duplicate of 3108 ***

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