Assignee: asa → jst
Component: Browser-General → DOM Level 0
QA Contact: doronr → desale
let's ignore the crash on close widget (that's unrelated). I think this bug is more useful than another bug for the same issue, so i'll probably dupe that on this.
*** Bug 73577 has been marked as a duplicate of this bug. ***
actually, maybe we shouldn't ignore the crash.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash, stackneeded
I need a stacktrace (or talkback data) for the crash to know where to start looking, is this linux only? To be able to look into this I need access to a MS Excange/Outlook Web Access account somewhere, does anybody have ideas where to get access to such an account? Cc:ing mstoltz since there seems to be a security problem here as well.
Hello again. Thanks for the interest in this, guys. In answer to Johnny's three questions (not quite in the order asked): No, it's not confined to Linux. I have replicated this under WinNT 4.0, sp6a using Build ID 2001032704 (sorry it's not the very latest, but connectivity to ftp.mozilla.org has been dreadful this evening - I used www.mirror.ac.uk/sites/ftp.mozilla.org which is a day behind). Yes, of course you can have TalkBack data. Incident IDs TB28390380Q and TB28390451M correspond to the above replication under NT. I sent two more at 00:37 and 00:43 BST 29/03/2001 which strangely are showing as sent but has no Incident ID... Maybe Talkback5.netscape.com doesn't like me any more ;-) I'll try to get you some Linux Talkback data RSN (ie at the weekend). Since it crashes before the login page loads, you don't really need an account, so try any of these: http://ragingsearch.altavista.com/cgi-bin/query?q=%22Outlook+Web+Access%22 Trim the results to "http://host.domain.tld/Exchange" - it seems it's during the redirect that it dies. And AFAICT, it only happens if you click in the URL while it's faffing (it seems to go to sleep). I wondered if it was a combination of a problem understanding MS-style redirects (do they even do 302s in a nonstandard way?) and lack of arbitration on some "current URL" data between server redirect processing and the GUI handler, but I can't replicate this at URLs I know to be IIS 4 issuing 302s. If I get a chance tomorrow I'll try it on an WinNT box with Naviscope (note to casual readers: Naviscope is a Win32 local proxy which logs _everything_). Bis morgen...
Me /again/ (don't worry I'm going to bed soon). Had a look at bug 73577. With all due respect to Timeless, that's not a dup of this bug. The crash-on-reply (and delete, and move-to-filing-cabinet) problem I have had (a lot) in 0.8 under Linux, but it seems to be fixed in 2001032708 (hence I didn't report it). In case anyone cares, it seemed to be related to whether a dud request had been left to time out or not. I sent a lot of Talkback data on this at the time (inc TB28123721M, TB28126219W, TB28114659X) and hey, someone fixed it. Magic ;-)
So this could be closed then, right? I know the NS_ERROR_INVALID_POINTER problem has shown up on similar pages before and nobody has been able to reliably reproduce it so if that comes back please let us know. Marking as WORKSFOME (I wasn't able to crash mozilla using any of the links you supplied), please reopen if this one comes back...
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Resubmitted better characterisation as bug 73928. Marking this as dup of that. *** This bug has been marked as a duplicate of 73928 ***
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.