11883 - [PP]app closes when select submit on form

Status: VERIFIED DUPLICATE of bug 12198

(Core :: DOM: Core & HTML, defect, P3)

Description

[rubydoo123]

build: 1999081308
platform: win98
other platforms: unknown at this time

URL: http://www.mozilla.org/quality/browser/bft/bft_browser_form.html

minimized test:
<FORM METHOD=GET ACTION="mailto:[e-mail]">
<INPUT TYPE=TEXT NAME="comment_text" SIZE=30 MAXLENGTH=25>
<br><br>
<INPUT TYPE=SUBMIT VALUE="Submit Order">&nbsp;|&nbsp;<INPUT TYPE=RESET
VALUE="Reset Form">
</FORM>

what happened: when I selected submit, the app closes

expected results: I expected the form to be emailed to me.

how to reproduce:
1. copy code into a test html file
2. enter some bogus text in text field
3. select submit
-- system quits

NOTE: I also tried POST and the same action resulted.

Comment 1

[karnaze (gone)]

Reassigning to Kevin.

Comment 2

[Kevin McCluskey (gone)]

It's dying in a call to nsIOService::NewURI

Looks like a necko issue.


Here's the stack:

_NMSG_WRITE(int 255) line 221
_FF_MSGBANNER() line 169 + 10 bytes
_amsg_exit(int 25) line 324
_purecall() line 35 + 7 bytes
nsIOService::NewURI(nsIOService * const 0x00bdd5a0, const char * 0x09c641c0,
nsIURI * 0x00000000, nsIURI * * 0x0012fdcc) line 208 + 35 bytes
NS_NewURI(nsIURI * * 0x0012fdcc, const char * 0x09c641c0, nsIURI * 0x00000000)
line 36 + 24 bytes
NS_NewURI(nsIURI * * 0x0012fdcc, const nsString & {...}, nsIURI * 0x00000000)
line 49 + 17 bytes
nsWebShell::LoadURL(nsWebShell * const 0x00bddbf0, const unsigned short *
0x09c64a00, const char * 0x00fe8b48, nsIInputStream * 0x09c655e4, int 1,
unsigned int 0, const unsigned int 0) line 2155 + 18 bytes
nsWebShell::LoadURL(nsWebShell * const 0x00bddbf0, const unsigned short *
0x09c64a00, nsIInputStream * 0x09c655e4, int 1, unsigned int 0, const unsigned
int 0) line 1915
nsWebShell::HandleLinkClickEvent(nsIContent * 0x09d12c80, nsLinkVerb
eLinkVerb_Replace, const unsigned short * 0x09c64a00, const unsigned short *
0x00b45ad0, nsIInputStream * 0x09c655e4) line 3028
OnLinkClickEvent::HandleEvent() line 2855
HandlePLEvent(OnLinkClickEvent * 0x09c67780) line 2868
PL_HandleEvent(PLEvent * 0x09c67780) line 509 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00b95d60) line 470 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00850858, unsigned int 49419, unsigned int 0,
long 12148064) line 932 + 9 bytes
USER32! 77e71250()
00b95d60()

Comment 3

[rubydoo123]

thanks Kevin -- I'm sure the stack will help a lot.

Comment 4

[Gagan]

mailto! hmmm.... mail guru gets this.

Comment 5

[Scott MacGregor]

Can someone verify if the submit still crashes for them? I'm returning an error
code that NewURI isn't implemented for mailto urls yet. If the crash is still
there then it means the webshell is ignoring the failure code and continue past
it.

Comment 6

[Scott MacGregor]

I don't believe this crashes anymore. This bug was filed back in early Agust and
all the mailto stuff has been revamped. It doesn't work (as in it one run the
mail to url) since we don't have url dispatching going yet, but we have other
bugs to track that. This bug is for the crash that was reported in August.

I'm going to mark

Comment 7

[Chris Petersen]

With the Sept 28th Win build, clicking the submit button nolonger crash the
application. It now correctly opens a messanger window. However, the Mac and
Linux Sept 29th builds both crash after clicking on the Submit button. I will
reopen this report and check in the next build to see if the fix has been
implemented.

Comment 8

[Phil Peterson]

Can we get a talkback ID or stack trace to find out where the problem is? Crash
on form submission isn't likely to be mscott's bug.

> It now correctly opens a messanger window

I don't think that's the correct behavior. A mailto in a form submit isn't
supposed to open a window -- it's supposed to mail the form contents silently.

Comment 9

[Chris Petersen]

Crash still occurs on the Oct 1 Mac build.

Here is the call stack:




   .__ptr_glue


   nsString::~nsString()
                                               [nsString2.cpp, line 121]

   nsDeleteObserved::~nsDeleteObserved()
                                               [nsDeleteObserver.cpp, line 45]

   nsWindow::~nsWindow()
                                               [nsWindow.cpp, line 175]

   nsChildWindow::~nsChildWindow()
                                               [nsChildWindow.cpp, line 36]

   nsBaseWidget::Release()
                                               [nsBaseWidget.cpp, line 34]

   layout.shlb + 0xad4bc (0x047b829c)


   layout.shlb + 0xad5a8 (0x047b8388)


   nsCOMPtr_base::~nsCOMPtr_base()
                                               [nsCOMPtr.cpp, line 26]

   layout.shlb + 0x14440 (0x0471f220)


   layout.shlb + 0x13b80 (0x0471e960)


   layout.shlb + 0x14598 (0x0471f378)


   layout.shlb + 0xa7718 (0x047b24f8)


   layout.shlb + 0xa785c (0x047b263c)


   DOM_DLL + 0x8da18 (0x05629e58)


   DOM_DLL + 0xa5948 (0x05641d88)


   js_FinalizeObject()
                                               [jsobj.c, line 1354]

   js_GC()
                                               [jsgc.c, line 892]

   js_ForceGC()
                                               [jsgc.c, line 671]

   JS_GC()
                                               [jsapi.c, line 1096]

   DOM_DLL + 0x6668 (0x055a2aa8)


   DOM_DLL + 0x13df4 (0x055b0234)


   layout.shlb + 0x291070 (0x0499be50)


   layout.shlb + 0x290d6c (0x0499bb4c)


   nsWebShell::Embed()
                                               [nsWebShell.cpp, line 869]

Comment 10

[Scott MacGregor]

This definetly isn't a mailnews problem. WE need to figure out who owns form
submission and re-assign it to them.

Comment 11

[leger]

cpratt, can you please check with latest builds all platforms and give us info
so we know what to Release Note for M10.  Moving to M11.

Comment 12

[karnaze (gone)]

Gagan, this may be yours.

Comment 13

[Mats Palmgren (inactive)]

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

Comment 14

[Paul MacQuiddy]

this looks like a duplicate of 12198

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