Build ID: 1999101408 Platform: Windows NT To reproduce: - Launch apprunner (I used the commercial build) - Go to excite.com (it's on our smoke test list) - Type something into the text input control (I used 'Hello Kitty') - Click Submit Result: You crash. Expected result: The form is correctly submitted, etc. A Talkback report was generated: no. 14238904 - I'd provide a link but the search is taking aeons.

Reassigning to Kevin.

It is failing in nsHTTPChannel::Open(void) channel is nsnull nsDebug::Error(const char * 0x022356c8, const char * 0x02235690, int 638) line 305 + 13 bytes nsHTTPChannel::Open() line 638 + 21 bytes nsHTTPChannel::AsyncRead(nsHTTPChannel * const 0x026fb8e0, unsigned int 0, int -1, nsISupports * 0x00000000, nsIStreamListener * 0x026ff890) line 256 + 8 bytes nsDocumentBindInfo::Bind(nsIURI * 0x02639100, nsILoadGroup * 0x00c870f0, nsIInputStream * 0x00000000, const unsigned short * 0x02767ef0) line 1082 + 45 bytes nsDocLoaderImpl::LoadDocument(nsDocLoaderImpl * const 0x00c87160, nsIURI * 0x02639100, const char * 0x00f8c064, nsIContentViewerContainer * 0x00c86130, nsIInputStream * 0x00000000, nsISupports * 0x00000000, unsigned int 0, const unsigned int 0, const unsigned short * 0x02767ef0) line 511 + 32 bytes nsWebShell::DoLoadURL(nsIURI * 0x02639100, const char * 0x00f8c064, nsIInputStream * 0x00000000, unsigned int 0, const unsigned int 0, const unsigned short * 0x02767ef0) line 2107 + 57 bytes nsWebShell::LoadURI(nsWebShell * const 0x00c86130, nsIURI * 0x02639100, const char * 0x00f8c064, nsIInputStream * 0x00000000, int 1, unsigned int 0, const unsigned int 0, nsISupports * 0x00000000, const unsigned short * 0x02767ef0) line 2174 + 32 bytes nsWebShell::LoadURL(nsWebShell * const 0x00c86130, const unsigned short * 0x02767700, const char * 0x00f8c064, nsIInputStream * 0x00000000, int 1, unsigned int 0, const unsigned int 0, nsISupports * 0x00000000, const unsigned short * 0x02767ef0) line 2328 + 52 bytes nsWebShell::LoadURL(nsWebShell * const 0x00c86130, const unsigned short * 0x02767700, nsIInputStream * 0x00000000, int 1, unsigned int 0, const unsigned int 0, nsISupports * 0x00000000, const unsigned short * 0x02767ef0) line 1907 nsWebShell::HandleLinkClickEvent(nsIContent * 0x01f8db70, nsLinkVerb eLinkVerb_Replace, const unsigned short * 0x02767700, const unsigned short * 0x00297178 gCommonEmptyBuffer, nsIInputStream * 0x00000000) line 3062 OnLinkClickEvent::HandleEvent() line 2885 HandlePLEvent(OnLinkClickEvent * 0x02762380) line 2898 PL_HandleEvent(PLEvent * 0x02762380) line 541 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00c3ad60) line 500 + 9 bytes _md_EventReceiverProc(HWND__ * 0x039209f0, unsigned int 49459, unsigned int 0, long 12823904) line 970 + 9 bytes USER32! 77e71820() 00c3ad60() Appears to be a Necko issue. Setting component to Necko - reassigning.

Putting on [PDT+] radar.

This also crashes the 1999101415 Linux build. The Mac 1999101411 build behaves differently: it doesn't crash, but instead goes to a Netcenter page. It looks as if Smart Browsing is kicking in (?). BTW, the URL generated appears to be this: http:///r/co=me_srch_+ex;http://search.excite.com/search.gw?search=hello%20kitty I can't copy and paste it in to apprunner due to another bug right now though.

Rick: you looking at posting...

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

I've just checked in a fix for this... The problem was that when redirecting a URL, the HTTPChannel would copy over the Ref, Param and Query of the old URL to the new redirected URL... This was wrong. Only the Ref of the original URL should be copied... The original code was put in to fix bug# 9040.

In the 1999110508 build (NT), it's not crashing, and it's even working correctly! Verified fixed.

I see this one crashing again (on linux). The reason seems to be a path to an add that's bogus: This is the readable part of the path: /iframe;spacedesc=FreeWallpaper2_Excite_468x60_RunOfSite_Any&time=1999.11.24.12.40.23&ex_cookie=FD902BF438123006&ML_TARGET=_top&ML_REDIRECT=http After that it continues with a whole load of garbage resulting in a crash. Maybe this is a layout bug which fails to add a \0 when cutting out the path to the add. Reopening.

Clearing FIXED resolution due to reopen.

Moving to M12 since M11 is over and this has been reopened.

I am unable to reproduce this (win NT) andreas, you still seeing it on Linux?

I also don't see this anymore on linux. Must have been solved with one of the form layout and submission bugs last week. Sometimes bugs fix themself by waiting ;-)

Looks like it's fixed now.

Marking VERIFIED FIXED on: - WinNT 1999120608 mozilla Also tested (and behaves correctly) on: - Linux6 1999120608 mozilla - MacOS86 1999120608 mozilla

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