68321 - form.submit() causes NS_ERROR_INVALID_POINTER

Status: VERIFIED FIXED

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

Description

[Gilles Durys]

2001020904 trunk win98
20010208xx trunk linux

When I try to delete mails from my webmail account, I get a page telling me that
I don't have a Javascript-enabled browser.
2 or 3 days ago, it worked.

Also I, of course, have Javascript enabled (I tried without but there I can't
even log into my account - which is perfectly normal)

No problem on explorer, Netscape4 and Opera

Comment 1

[Gilles Durys]

More comments:
it seems to happen randomly

Comment 2

[Phil Schwartau]

Browser, not engine. This problem can be caused by a browser-sniffing
error, for example a failure by the site to recognize the navigator.userAgent 
string of the given browser. however, Gilles' remark that the error is 
intermittent suggests that is not the case here.


My own experience: when I use Mozilla binary 2001020904 on WinNT, 
I have been able to delete mail from the site every time I've tried. 



The HTML behind the "Delete" button is as follows:


 <a HREF="no_javascript.tmpl" onClick="return doDelete(document.msgmgmt)"  etc.


I guess this means that the onClick event handler will attempt to execute
the JavaScript doDelete function, and if for some reason it cannot execute 
the function, it will put up the HREF= no_javascript.tmpl"


I will attach a reduced example below showing this behavior. 
In this case, the JavaScript cannot execute because I have removed 
the JavaScript functions.


In the meantime, reassigning to Browser-General for advice on this one.
Perhaps a similar problem has been experienced by other users? By the 
way, if anyone has a test account at this site, could they please put 
the username and password into this bug? Thanks - 

Comment 3

[Phil Schwartau]

Attachment: HTML example of the behaviour

Comment 4

[Phil Schwartau]

When you bring up the HTML example above, and click the "Delete" button,
the JavaScript calls cannot be resolved because I have removed all the
JavaScript functions from the file. What happens is you get the 
"no_javascript.tmpl" page mentioned above coming up, telling you that you 
do not have the correct type of browser, or do not have JavaScript enabled.


This is false and misleading, as you can see. As to why the JavaScript 
is intermittently failing to resolve at the given site, I have no idea. 
Anyone who can reproduce this bug (I can't), please use 


                 Tasks | Tools | JavaScript Console 


and see if there are any helpful error messages there. 

(Note: it is a good idea to bring this up first, before you test, 
and clear out any accumulated error messages from previous sites...)


And again, if anyone knows of a test account we can use to test the
site out, please indicate what the username and password are. Thanks -

Comment 5

[Phil Schwartau]

Idea: is this perhaps a timing issue? 

Is the HREF being activated before the onClick event handler kicks in - 
exactly the opposite of what the site would like? 

Comment 6

[Gilles Durys]

Just happened again.
Following Phil's advice, here's the error in the javascript console:

uncaught exception: [Exception... "Invalid pointer" code: "-2147467261"
nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location:
"http://ncmail02.netscape.com/webmail/br/msglst.js Line: 95"


Same error comes back every time I fail to delete mails.

Comment 7

[Phil Schwartau]

Attachment: msglst.js

Comment 8

[Gilles Durys]

I created a test account
login: bug68321
pass: bugzilla

Comment 9

[Phil Schwartau]

Thanks, Gilles!


According to my text editor, line 95 of msglst.js is this: 



function _doDelete(theform)
{
 theform.cmd.value="deleteMessage";
 theform.submit();  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< LINE 95
}



The function _doDelete() only gets called from the function doDelete(): 



function doDelete(theform)
{
  if (theform)
  {       
    if (anyChecked(theform) == false)
            alert(s_msglstjs_deletenoselect);
    else
    {
      if( msgDeleteConfirm )
      {
        if( confirm(s_msglstjs_deleteconfirm) )
              _doDelete(theform);
      }
      else
              _doDelete(theform);
    }
  }
  return false;
}

Comment 10

[Phil Schwartau]

Since the error occurs on line 95 above:


                      theform.submit()


reassigning to Form Submission for further triage - 

Comment 11

[Vladimir Ermakov]

I've seen a simular problem in Hotmail, you cant delete messages, and onclick is 
also calling .submit();

Comment 12

[HJ]

I have seen this error to many times, so I can confirm this.

Comment 13

[rods (gone)]

reassigning

Comment 14

[Jesse Ruderman]

Probably the same problem as bug 68342.

Comment 15

[Eric Pollmann]

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

Comment 16

[Eric Pollmann]

Making summary more specific.

Comment 17

[HJ]

I'm working on 46029 and I discovered that if I change the userAgent a bit, then
the same error apears! So this might be some sort of strange HTTP issue where
the useragent is damaged. I will investigate this further to trace the error. I
will report a.s.a.p.

Comment 18

[Gilles Durys]

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

Comment 19

[Fabian Guisset]

All checkins by Eric Pollmann between the 5th and 9th of february :
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=pollmann&whotype=regexp&sortby=Date&hours=2&date=explicit&mindate=02%2F05%2F2001&maxdate=02%2F09%2F2001&cvsroot=%2Fcvsroot

Comment 20

[Eric Pollmann]

:S Not seeing this with a recent debug build.  (Deleting emails on
webmail.netscape.com works, and the bug marked a dup won't show errors on the JS
console for me)  I'll see if i can reproduce this on my machine with daily
builds from mozilla.org...

Comment 21

[Eric Pollmann]

I *am* able to reproduce this bug on a build form February 9th, but am *not*
able to reproduce this bug on a build from today (downloaded from mozilla.org).
 Can the reporters of this bug please download the latest builds to verify if it
was also fixed for them?  Thanks!

This is the build I used that worked on Win32:
http://ftp.mozilla.org/pub/mozilla/nightly/2001-03-20-06-Mtrunk/

Comment 22

[HJ]

Eric, do you know what change is made to fix this bug?

Comment 23

[jsp]

The behavior is definitely improved, but not perfect. Using the test case
outlined in bug 68342 on 2/12/01, the call to form.submit() succeeds, but I
still see the NS_ERROR_INVALID_POINTER in the JavaScript console. The console
message indicates that the error occurred in the form.submit() call. It's as if
the code detects and reports the error, then tries a different approach that
works. Or it might just be reporting an error where none exists.

Comment 24

[jsp]

Forgot to mention that I tested with the most recent nightly posted on
www.mozilla.org, with build ID 2001031604.

Comment 25

[Michael Witbrock]

The bug doesn't seem to be affecting me in today's build. However, it's hard to
know for sure, since it was intermittent, and there's a natural (but large)
limit on the supply of available junkmail to delete :-)

Comment 26

[jsp]

The test case in bug 68342 behaves the same in 2001032004 as in 2001031604. In
other words, it's still broken, but in a rather benign way.

This bug is easily and reliably reproducible as follows (copied from bug 68342):

1) Shut down Mozilla if it's running.
2) Launch Mozilla.
3) Open the JavaScript console and clear any messages.
4) Load http://bugzilla.mozilla.org/showattachment.cgi?attach_id=24916 (the test
case).
5) Create a new browser window (Ctrl-N on Windows, Command-N on Macintosh).
6) Close the new window.
7) Click the text (not the submit button) in the document in the original window.

At the moment, the expected behavior occurs, but you also get the
NS_ERROR_INVALID_POINTER message in the JavaScript console.

If I could change this from RESOLVED WORKSFORME, I would.

Comment 27

[Eric Pollmann]

[e-mail], what platform are you on?  Based on the date of 2001-03-16-04, it
must be Mac, right?  (couldn't find a 2001032004?) I only tested this on Windows
NT 2001032006.  Anything else peculiar about your setup?  Extremely fast/slow
CPU, dual cpu?  Lots of/little memory?  Fast/slow internet connection?  Have you
done your own debug build and seen it?  Reason I ask is, I get the impression
this just might be a timing thing...

H-J, I haven't got a clue what caused or fixed this bug - and apparently it
isn't fixed!

Reopening per reporter comments, sorry - guess it was wishful thinking.  :)

Comment 28

[Eric Pollmann]

Ack!  No fun.  Okay, I can reproduce this with the 032006 build on Win NT too
now, but I can't reproduce it in my debug build.  :S  I'll try to do an
optimized build from today's tree and see if I can reproduce it.  Hopefully the
Gods of timing will be smiling on me trying to debug this thing...

Comment 29

[jsp]

FWIW, I'm testing on Windows 2000 as well. I haven't made a debug build myself;
my plate's so full the dog's getting fat on what falls off.

I wish you luck reproducing this in a debug build. Nuthin' worse than a bug that
only shows up in retail builds.

Comment 30

[Michael Witbrock]

I hit the bug again in netscape mail today, on Build 2001032004, so while it
seems to have been ameliorated by whatever happened in recent bugs, I can
confirm that it's not fixed.

Comment 31

[HJ]

Hi people,

I'm on assignment in Spain for work and just checked my netscape webmail from 
Spain with Netscape 4.08. Same error, same Netscape Webmail page!!

So _is_ this a Mozilla bug, because now i'm not so sure about that any more! 
This might be some sort of strange bug in those Netscape pages!? And if not, why 
did it show the same page in this 'older' version of Netscape??

Comment 32

[jsp]

It's hard to see how it could be (entirely) a bug in Netscape's pages.
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=24916
provides a very simple test case that failed with Mozilla, though it works with
NS 6.01 and a recent nightly (2001040120 for Windows). Unfortunately, I don't
think NS 4.08 will know quite what to make of it.

Comment 33

[Michael Witbrock]

Well, whether it's a Mozilla bug, or a webmail bug, it would be 
good to get it fixed. It's awful that I have to use internet explorer to access 
a Netscape product reliable, and bad PR.

One thing that's notable about it is that once the failure happens the first
time (it doesn't always fail), all deletes from then on fail with the same error
message.

I think it's something like a mozilla bug, since it's never happened to me
using netscape 6.01 (but maybe that's just due to less 6.01 use). There *are*
all sorts of reliability issues with webmail IMAP integration in 6.01 though.  

The whole webmail integration/access thing, which could be a *GREAT* feature, is
a big mess.

Comment 34

[HJ]

Can a missing referrer cause this behaviour? That new opened window seems to be
missing a referrer! Should this be assigned to 'Networking HTTP' then?

Comment 35

[jsp]

This seems to have gotten worse lately. Since 3/21, the only sign of this bug
I've seen has been the console error message. Despite the message, forms have
been submitting fine. With 2001042615 (which, as near as I can tell, is a 0.9
candidate at the moment), the form sometimes does NOT submit. I haven't been
able to come up with a simple test case that demonstrates the failure to submit,
unfortunately. My earlier test case still generates the console message.

Comment 36

[Ken Snider]

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

Comment 37

[Steve Zweep]

Also seeing this error in a custom app. we've developed. Am attaching a simple
test case that shows the submit() failure. Running under Win 2000, installer
build 2001050320. Javascript console shows this:

Error: uncaught exception: [Exception... "Invalid pointer"  code: "-2147467261"
nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location:
"http://mojo/test.html Line: 13"]

Comment 38

[Steve Zweep]

Attachment: Test case showing onClick form submit failure.

Comment 39

[Xuân Baldauf]

Hello, it seems that the bug depends on the process context of the javascript
interpreter. The bug seems to happen if the function which submit()s is called
by a function which is called by setTimeout(), while, if invoked directly from
an event handler, it does not seem to happen.

Comment 40

[Xuân Baldauf]

Okay, it does not seem to be process context dependent, boths ways to submit
fail if a window was opened and closed before.

Test case:

1. Go to "http://justchat4.medium.net:4000/chat/test/mozilla/formSubmit/".
2. Click on "submit directly". You should get an alert window popped up.
3. Open a new browser window (Ctrl+N).
4. Close that window (Alt+F4).
5. Click on "submit directly". Now you do not see the alert window, but the
JavaScript error in the JavaScript console.

Comment 41

[jsp]

Cool. This EXACTLY mirrors my experience. (See my comments of 3/21/01.) Eric,
did you ever succeed in reproducing this with a debug build?

Comment 42

[Jan Ptacek]

hi all.
i got this bug on my page, where i get by changing frame url by script.
there I  have a form, again I change some value in it by script 
and then i try to submit it using 
myF = document.getElementById("myForm");
myF.submit();
and here it is :
Error: uncaught exception: [Exception... "Invalid pointer"  code: "-2147467261" 
nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  
location: "http://p.3web.cz/sformeditreplace.php Line: 38"]
on line 38 : 
and there, bet it : myF.submit();
but effect is ok, the form is submited and processed
thx in advance for anything related
[e-mail]

Comment 43

[wkfx2003-bugzilla]

I believe my site encounter this bug too. A simple test form can prove 
my build is 2001051804

<form name="f" action="right.jsp" method="get">
<input name="tf" value="2">
</form>
<a href="wrong.jsp" onClick="document.f.tf.value='3';document.f.submit();return
false;"> 3 </a>

JavaScript console:
Error: uncaught exception: [Exception... "Component returned failure code:
0x80004003 (NS_ERROR_INVALID_POINTER) [nsIDOMHTMLFormElement.submit]"  nsresult:
"0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: <unknown
filename> :: onclick :: line 0"  data: no]


and the browser goes to "wrong.jsp" ("normal" because usually JS fail will goes
to the href). What's ABNORMAL is that the Javascript should works. It worked
fine in NS4 and IE4,5

Comment 44

[Gilles Durys]

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

Comment 45

[HJ]

I guess this is just one of those Netscape nightmares. They promote to use
WebMail, but wtf it aint working with there own product(s)! But wait, there's
the good news, it's on the 0.9.2 radar :)

1 - open your Netscape WebMail addressbook
2 - add an entry to your e-mail
3 - click on send
4 - bang, WebMail transformed itself into BadMail and you just lost your data!

TIP: make sure to copy your data with CTRL-C BEFORE trying to send your data!!!!

Comment 46

[HJ]

Hey, this error is only reproducible after closing that new window. If you don't
close that new opened window, then you won't see that error. It looks to me that
when the cleanup for that new window is done, some code is over eager flushing
data down the drain.

Comment 47

[Eric Pollmann]

Attachment: patch, remove secureBrowserUI from submit observer list on destruction

Comment 48

[Eric Pollmann]

Thanks to everyone contributing valuable information on how to reproduce this, I
was finally able to nail it down in a debugger.  Above is a patch that fixes the
problem and should prevent others like it in the future.

The problem was that a secureBrowserUIImpl, which pops up the warning dialog
before submitting a form, is created one per window, and each registers as a
form submit observer.  On teardown of the window, the secureBrowserUIImpl would
go away, but never remove itself from the observer list.  Then, when we tried to
notify it, the observer enumerator's CurrentItem() would return an error code.

The fix was:
1) Make secureBrowserUIImpl unregister itself from the submit observer list
   on destruction, and
2) Make form submission simply skip over any observers that return error codes
   when calling CurrentItem, rather than skipping, then later returning the
   error code.

Comment 49

[Eric Pollmann]

Javier or David, Johnny, can you provide r=/sr= for this patch?  Thanks!

Comment 50

[Johnny Stenback (:jst)]

sr=jst

Comment 51

[Javier Delgadillo]

r=javi

Comment 52

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 53

[HJ]

Thanks for the patch Eric, great to see this go away :)

Comment 54

[Eric Pollmann]

Javier, I attempted to check in this patch and recieved the following message:

pollmann PC609916(11):/builds/pollmann/mozilla> cvs ci -m "Bug 68321: Remove nsS
ecureBrowserUIImpl from form submit observer list on destruction, and ignore fai
lures when enumerating observer list.  These failures were causing spurious NS_E
RROR_INVALID_POINTER messages on the console, and preventing form submission.  r
=javi@netscape,com, sr=[e-mail], a=[e-mail] (asa)" security/m
anager/ssl/src/nsSecureBrowserUIImpl.cpp layout/html/forms/src/nsFormFrame.cpp

You may not check into partition security
the file mozilla/security/manager/ssl/src/nsSecureBrowserUIImpl.cpp on branch HE
AD
If you think you should be allowed to, send mail to
one of the below people:
  [e-mail]
  [e-mail]
  [e-mail]
  [e-mail]
  [e-mail]
  [e-mail]
  [e-mail]
  [e-mail]
  [e-mail]
  [e-mail]
  [e-mail]
  [e-mail]
cvs server: Pre-commit check failed
cvs [server aborted]: correct above errors first!
pollmann PC609916(12):/builds/pollmann/mozilla>

I went ahead and checked the patch into nsFormFrame.cpp so that the problem
would be ignored.  Can you please check in the patch to
nsSecureBrowserUIImpl.cpp, unregistering the nsSecureBrowserUIImpl from the form
submit observer list on destruction?  Please tell me if I need to take further
action.  Thanks!

Comment 55

[Javier Delgadillo]

I've checked in the portions to
security/manager/ssl/src/nsSecureBrowserUIImpl.cpp that were in the patch.

Marking fixed.

Comment 56

[Eric Pollmann]

Thanks Javier!

Comment 57

[jsp]

WFM with 2001062009 on Windows 2000. Nice work!

Comment 58

[Vladimir Ermakov]

Verifying build 2001-06-21-04-trunk windows 98
and 2001-06-20-21-trunk linux redhat 6.2