If you have an URL like http://some.domain.com/foo#/1/2 this breaks the parser. Similarly http://some.domain.com/foo?/1/2 will break as well. If you are wondering were these kinds of constructs might come up, check the 990709 draft of XPointer (http://www.w3.org/TR/WD-xptr). Below is a monster URL that is a valid URL + XPointer but will choke the parser: http://me.com/foo#xptr(id("ref37")/ancestor::*/attribute::lang[position()=last() ]/string::3,"Thomas Pynchon",8) I have made an XPointer component but I cannot use it because of this...

The patch (id=1616) fixes relative URLs that start with # or ?. The case with # is a bit strange - in the course of creating this there are times when wrong data members are filled with wrong values, but eventually the correct URL is created. This fix does not fix absolute nor relative URLs that do not begin with # or ?. After lookin at the Parse() method I would be more than willing to pass this to the person who wrote Parse() in the first place...

I have a fix for this, waiting for review ...

fix checked in ...

thanks Andreas.

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

Verified these in debugger, nsStdURL:GetSpec() with following URLs: target.html?/1/3#/5/6 target.html?/1/3#/5/6/slot('?#/') target.html?/1/3#/5/6/slot('\?#/') All the member variables seem to hold correct values.