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

More comments: it seems to happen randomly

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 -

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 -

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?

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.

I created a test account login: bug68321 pass: bugzilla

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; }

Since the error occurs on line 95 above: theform.submit() reassigning to Form Submission for further triage -

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

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

reassigning

Probably the same problem as bug 68342.

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

Making summary more specific.

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.

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

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

: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...

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/

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

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.

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

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 :-)

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.

jsp@pkc.com, 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. :)

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

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.

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.

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??

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.

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.

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?

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.

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

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"]

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.

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.

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?

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 p@email.cz

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

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

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!!!!

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.

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.

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

sr=jst

r=javi

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

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

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=jst@netscape.com, a=drivers@mozilla.org (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: wtc@netscape.com sonmi@netscape.com nicolson@netscape.com nelsonb@netscape.com mcgreer@netscape.com larryh@netscape.com kirke@netscape.com javi@netscape.com chrisk@netscape.com thayes@netscape.com relyea@netscape.com ddrinan@netscape.com 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!

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

Thanks Javier!

WFM with 2001062009 on Windows 2000. Nice work!

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