M$ Exchange/Outlook Web Access rendered unusable since 0.8

VERIFIED DUPLICATE of bug 73928

Status

()

--
critical
VERIFIED DUPLICATE of bug 73928
18 years ago
17 years ago

People

(Reporter: mozbugs, Assigned: jst)

Tracking

({crash, stackwanted})

Trunk
x86
Linux
crash, stackwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
I have been testing 0.8.1 on my system (yes, I can read - this problem's present
in the trunk too - in fact it's worse), having been using 0.8 for a while now.

This is similar to several other problems which apparently show on
Frontpage-built sites (so we can blame the Empire), but I couldn't find anything
specific enough to add this to.

It seems there are some new holes in the Javascript engine, and in loading pages
generally, which show up when you try to use M$ Exchange/Outlook Web Access.  I
need do this every day, so it's a total show-stopper for me at the moment (and
probably for lots of others with similarly unenlightened employers).

Here's some output, running from a freshly un-tgz-ed download:

+--

[duncan@mybox mozilla-0.8.1]$ ./mozilla
./run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=/home/duncan/teststuff/mozilla-0.8.1
  LD_LIBRARY_PATH=/home/duncan/teststuff/mozilla-0.8.1
    
LIBRARY_PATH=/home/duncan/teststuff/mozilla-0.8.1:/home/duncan/teststuff/mozilla-0.8.1/components
       SHLIB_PATH=/home/duncan/teststuff/mozilla-0.8.1
          LIBPATH=/home/duncan/teststuff/mozilla-0.8.1
       ADDON_PATH=/home/duncan/teststuff/mozilla-0.8.1
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"
Error loading URL http://exchangeserver.myemployer.com/: 804b0002
Error loading URL http://exchangeserver.myemployer.com/exchange/logon.asp: 804b0002
JavaScript error:
 line 0: uncaught exception: [Exception... "Invalid pointer"  code:
"-2147467261" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location:
"http://exchangeserver.myemployer.com/exchange/logon.asp Line: 30"]
`
Error loading URL JavaScript:sendForm(false): 804b0002

+--

Then every time you try to open a message (which are done with <a
HREF='JavaScript:parent.openNewWindow("/exchange/forms/IPM/NOTE/frmRoot.asp?index=3&obj=__Enormous_Exchange_Object_ID__&command=open",
"__Enormous_Exchange_Object_ID__", 640, 500)'>, where
__Enormous_Exchange_Object_ID__ is about 100 digits of hex), you get the
following error:

+--

JavaScript error:
 line 0: uncaught exception: [Exception... "Access to property denied"  code:
"1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)"  location:
"<unknown>"]

+--

This is worse in yesterday's nightly build (2001032708), which never even
displays the login page.  All I get is:

+--

Error loading URL http://exchangeserver.myemployer.com/: 804b0002
Error loading URL http://exchangeserver.myemployer.com/exchange/logon.asp: 804b0002

+--

At this point the URL box stops responding to keyboard input, and when I click
the close gadget, mozilla-bin segfaults:

+--
/home/duncan/teststuff/mozilla/run-mozilla.sh: line 72:  2100 Segmentation fault
     $prog ${1+"$@"}

+--

My system is a P-III/600 with some memory and stuff, running RedHat 7.0 plus
some bits of Wolverine (RedHat Beta 7.0.92) on a 2.4.2 kernel.  Neither of these
problems are present in 0.8 (2001021503) with Talkback.

Updated

18 years ago
Assignee: asa → jst
Component: Browser-General → DOM Level 0
Keywords: qawanted
QA Contact: doronr → desale
Whiteboard: DUPEME

Comment 1

18 years ago
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.

Comment 2

18 years ago
*** Bug 73577 has been marked as a duplicate of this bug. ***

Comment 3

18 years ago
actually, maybe we shouldn't ignore the crash.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash, stackneeded
Whiteboard: DUPEME
(Assignee)

Comment 4

18 years ago
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.
(Reporter)

Comment 5

18 years ago
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...
(Reporter)

Comment 6

18 years ago
PS: Thinking we might be able to fork this into two seperate bugs (ie feeling
guilty about the mess that is my initial report), I tried to reproduce the
Javascript bug after logging in:

Using 2001032704 under NT, another bug blocks investigation.  It seems to start
work (you get to do the simple-auth username and password stuff), but before it
finishes drawing all the frames, an alert appears which reads "Unable to get
renderer", and it bounces back to the login page.  This could be because the
machine in question has an ATI graphics card.  I'll look into this another time.

Using 2001032708 under Linux, the NS_ERROR_INVALID_POINTER and
NS_ERROR_DOM_PROP_ACCESS_DENIED problems have gone away, leaving only the
non-fatal "Error loading URL" messages.

Hurrah, I can use it again!

Night night.
(Reporter)

Comment 7

18 years ago
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 ;-)
(Assignee)

Comment 8

18 years ago
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
(Reporter)

Comment 9

18 years ago
This confusion is my fault for mixing up three (at least) distinct bugs in my
original submission.  The two Javascript-related ones which produce
NS_ERROR_INVALID_POINTER and NS_ERROR_DOM_PROP_ACCESS_DENIED are fixed in recent
nightlys.  However, these never did crash the browser, they just rendered
Exchange unusable.

There is a reproduceable way to make the thing segfault.  I will try to
characterise it better and submit a new bug.  I'll mark this as a dup of that
when I do.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 10

18 years ago
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 ago18 years ago
Resolution: --- → DUPLICATE

Comment 11

18 years ago
vrfy, thanks.
Status: RESOLVED → VERIFIED

Updated

17 years ago
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.