102341 - Crash when navigating from secure site to normal site. Win95, Win98

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[bht237]

Reproducible, but no testcase yet.
Quality Feedback Agent dumps will refer to this bug record
Build ID 2001092803.

It could be that the following error (visible in the script console)
triggers a JavaScript onerror handler whose execution causes the browser to
crash. Looks a bit like a racing condition.

JavaScript error:

Error: redeclaration of const kIOServiceProgID
Source File: chrome://communicator/content/utilityOverlay.js
Line: 1
This error has been in Mozilla for at least 2 weeks.

Comment 1

[Boris Zbarsky [:bzbarsky]]

reporter, do you have a talkback id for one of those talkbacks?

Comment 2

[bht237]

Some talkback IDs are:
TB36027633G
TB36029983Y
3 others are still in the queue but they have this bug ID as reference in the
comment.
I have been trying a whole day to get a testcase out of this but I can't :(

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

See bug 86238 for the JS error.  I don't think that is what's causing the crash,
though.  It is a known error that appears.  No crash has been known to come from it.

Comment 4

[bht237]

Attachment: child window

Comment 5

[bht237]

Attachment: parent window (opener)

Comment 6

[bht237]

I have found the problem and worked around it.
I am sorry the attached testcase does NOT reproduce the crash but it attempts to
describe the scenario in which it occurs.

The good thing is that it does not take me much effort to take the workaround
code out of the crashing system and re-test the bug with an updated build.

All other major browsers do NOT crash. A question: Does Mozilla's development
environment allow for fixing this bug with the talkback traces and the
information that has been provided so far?

Comment 7

[Boris Zbarsky [:bzbarsky]]

So... I tried that testcase, moving the close() call into doSomething() to try
to get it to crash.  I do not crash on current builds with that.

I have to ask.  Did you _purposefully_ attach the non-crashing testcase to make
this harder?  :)

I'll try to get the talkback traces, but so far this is worksforme.

Comment 8

[bht237]

yeah, I know, this is frustrating.
To be honest, It's desparation and hope why I created it. Have spent full 2 days
of my weekend to get to the bottom of it and now I can't even provide a crashing
testcase. In fact I must admit that I have zero evidence what causes it.
I was hoping to get a really ugly testcase that would crash. No such luck :(
I wish you have more luck than I.

Comment 9

[Asa Dotzler [:asa]]

Incident ID 36029983
Stack Signature 0x0308f18f da42ba67
Bug ID
Trigger Time 2001-09-28 21:01:58
Email Address [e-mail]
User Comments
Build ID 2001092809
Product ID MozillaTrunk
Platform ID Win32
Trigger Reason Access violation
Stack Trace
0x0308f18f
PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6037]
PresShell::FlushPendingNotifications
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4929]
nsDocument::FlushPendingNotifications
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3388]
GlobalWindowImpl::FlushPendingNotifications
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 3967]
GlobalWindowImpl::GetFrames
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 2409]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 139]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 1954]
XPC_WN_GetterSetter
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1287]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 809]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 900]
js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 2433]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2559]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 825]
nsXPCWrappedJSClass::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 1024]
nsXPCWrappedJS::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 430]
PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 102]
SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 124]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1214]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1733]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3719]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3700]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3700]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3700]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3700]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3700]
nsXULElement::HandleChromeEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 5105]
GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 616]
nsDocument::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3024]
nsEventStateManager::PreHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 462]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5705]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5635]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 377]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2076]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 737]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 754]
nsWindow::DispatchFocus
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4453]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3369]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1002]
KERNEL32.DLL + 0x3663 (0xbff73663)
KERNEL32.DLL + 0x22894 (0xbff92894) 

Comment 10

[Boris Zbarsky [:bzbarsky]]

layout

Comment 11

[bht237]

new talkback ID: TB363370 2001-10-06 build 2001100403
I think now that the chance that my pseudo-testcase describes any crash
condition is very low.

Comment 12

[bht237]

The new testcase reproduces the crash on my system (win95).
The corresponding talkback ID of the crash I sent is TB36339520K.

Finally! Good luck in catching this beast!

BTW my workaround has not been reliable. We definitely need a fix!

Comment 13

[bht237]

Attachment: parent window(opener) crashes!

Comment 14

[bht237]

The new testcase must be taken out of the Bugzilla context because the required
querystring confuses Bugzilla. You can copy the 2 files to your local file
system and get the crash from there!

Comment 15

[Boris Zbarsky [:bzbarsky]]

With those steps, still no crash on current debug build.

Comment 16

[Boris Zbarsky [:bzbarsky]]

No crash on current cvs opt, either.  Both on Linux.  Windows-only?

Comment 17

[bht237]

Part of the conditions leading to the crash ma be that the security dialog
warning of leaving the secure page is enabled:

[Security warning]
"You are about to leave an encrypted page"
[OK]

The crash occurs after I click OK on this dialog.

Did you see this dialog when testing?

I can reproduce the crash as often as I like.
Otherwise my whole system often runs for weeks without crashes.
I would say that my system is more stable than what users typically experience
with Windows.

How can I help?

Comment 18

[bht237]

I installed build 2001100403 on a different hardware/OS configuration: Win98
(other is Win95). Any Mozilla/Netscape 6.x were never installed on this. Tested
with sidebars on and all defaults.
The testcase (run from harddisk) crashes in the same way.
talkback ID: TB36357168Y

Comment 19

[Boris Zbarsky [:bzbarsky]]

> Did you see this dialog when testing?

I tried with and without that dialog when I tested.  Both were the same.

At the moment, it's just a matter of getting stacks from those talkbacks.

Comment 20

[Marc Attinasi]

I have tried numerous time on a couple of Windows 2K machines and my Mac and I
cannot reproduce this crash. Also, I cannot tell what is going on from the stack
trace attached (it looks like the presShell is corrupt or deleted or something).

Petersen, can you please try to duplicate this? Thanks!

Comment 21

[Chris Petersen]

I have been able to crash Mac OS X build with the test case provided. When
entering verisign site , I recieve "entering enccrypted site" dialog. Pasting
the url from the Opener window to replace the verisign url , caused the app to
crash after the throbber cycled for 10 - 20 seconds.
 

Comment 22

[Chris Petersen]

Date/Time:  2001-10-25 14:24:16 -0700
OS Version: 10.1 (Build 5L14)

Command:    Netscape 6
PID:        303

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x05cc7d70

Thread 0:
 #0   0x021da7bc in nsMacMemoryCushion::RecoverMemoryReserve(long)
 #1   0xbffff2f8 in 0xbffff2f8
 #2   0x021da724 in nsMacMemoryCushion::RepeatAction(EventRecord const &)
 #3   0x022025ac in Repeater::DoRepeaters(EventRecord const &)
 #4   0x021edfbc in nsMacMessagePump::DispatchEvent(int, EventRecord *)
 #5   0x021edb88 in nsMacMessagePump::DoMessagePump(void)
 #6   0x021ed418 in nsAppShell::Run(void)
 #7   0x01eb0374 in nsAppShellService::Run(void)
 #8   0x004bb39c in main1(int, char **, nsISupports *)
 #9   0x004bc078 in main

Thread 1:
 #0   0x7000530c in syscall
 #1   0x70557590 in BSD_waitevent
 #2   0x70554a30 in CarbonSelectThreadFunc
 #3   0x70020efc in _pthread_body

Thread 2:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x705594ac in CarbonOperationThreadFunc
 #3   0x70020efc in _pthread_body

Thread 3:
 #0   0x70043988 in semaphore_timedwait_signal_trap
 #1   0x70043968 in semaphore_timedwait_signal
 #2   0x7003fc38 in _pthread_cond_wait
 #3   0x7028366c in TSWaitOnConditionTimedRelative
 #4   0x7027cf10 in TSWaitOnSemaphoreCommon
 #5   0x702c14c8 in TimerThread
 #6   0x70020efc in _pthread_body

Thread 4:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x702505cc in TSWaitOnCondition
 #3   0x7027cef8 in TSWaitOnSemaphoreCommon
 #4   0x7024386c in AsyncFileThread
 #5   0x70020efc in _pthread_body

Thread 5:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x7055b9b4 in CarbonInetOperThreadFunc
 #3   0x70020efc in _pthread_body

Thread 6:
 #0   0x70001308 in mach_msg_overwrite_trap
 #1   0x70006394 in mach_msg
 #2   0x7017bebc in __CFRunLoopRun
 #3   0x701b6ba0 in CFRunLoopRunSpecific
 #4   0x7017b804 in CFRunLoopRunInMode
 #5   0x7061be08 in
XIOAudioDeviceManager::NotificationThread(XIOAudioDeviceManager *)
 #6   0x706141c0 in CAPThread::Entry(CAPThread *)
 #7   0x70020efc in _pthread_body

Thread 7:
 #0   0x70001308 in mach_msg_overwrite_trap
 #1   0x70006394 in mach_msg
 #2   0x700273dc in _pthread_become_available
 #3   0x700270d4 in pthread_exit
 #4   0x70020f00 in _pthread_body


PPC Thread State:
  srr0: 0x021da7bc srr1: 0x0000d030                vrsave: 0x00000000
   xer: 0x00000014   lr: 0x021da724  ctr: 0x021da70c   mq: 0x00000000
    r0: 0x021da724   r1: 0xbffff1b0   r2: 0x02264000   r3: 0x05cc7d70
    r4: 0x00008000   r5: 0x00000008   r6: 0x00000000   r7: 0x00000000
    r8: 0x000bd0a0   r9: 0x800013a4  r10: 0x059bd010  r11: 0x800033fc
   r12: 0x0225cf88  r13: 0x00000000  r14: 0x00000033  r15: 0x0005e690
   r16: 0x00000001  r17: 0x80160e88  r18: 0x0005a378  r19: 0x00001907
   r20: 0x00000000  r21: 0x0000001c  r22: 0x70004bc4  r23: 0x70004c58
   r24: 0x7016b214  r25: 0x006bac3c  r26: 0x8081ab5c  r27: 0xc0d89c00
   r28: 0x00000000  r29: 0xbfffef00  r30: 0x00000000  r31: 0x00000001

**********

Comment 23

[bht237]

Talkback ID TB38491942Z of another crash with build 2001111411

Comment 24

[Kevin McCluskey (gone)]

Marking nsbeta1+

Comment 25

[Marc Attinasi]

Working fine for me on Windows and Mac OS X builds (02/07) - marking WFM

Comment 26

[bht237]

What a pity! I was hoping this was fixed but when re-testing it I got another crash.
There is no talkback ID of it yet because it could not connect to the server but
I will provide it asap.

Comment 27

[bht237]

I have a Talkback entry waiting because Talkback cannot connect.
Shall I file a talkback issue?
Is there a way to get at the talkback info and paste it into this bug?

Comment 28

[bht237]

Users of all existing Netscape 6 versions complain about this crash.

They enter secure sites for purchasing goods and lose their shopping cart
when failing to return to the normal site to review their shopping cart contents.
Most users don't notify the site owners - they simply never come back.

I am raising the priority of this because the direct effect is
loss of data and business.

I am also cc'ing Brendan. Hopefully he can drive this to conclusion.
My apologies. I do not intend to hassle anyone here but I do not
know what else to do.

Comment 29

[Brendan Eich [:brendan]]

bht, do not change priority of others' bugs, that field belongs to the assignee.
You can always mail the assignee if you don't think he or she is giving the bug
the attention it deserves.  You can mail [e-mail] to nominate a bug
to block its milestone.  I've set that dependency now.

/be

Comment 30

[Marc Attinasi]

I think this might be the same problem as bug 121822 - I have a patch for that
one, but as I cannot reproduce this one I'm not sure if it will fix it.  bht,
can you try the patch in 121822?

Comment 31

[bht237]

Marc, I don't now how to patch i.e. I have no means of compiling Mozilla.
I added my email to the cc list of bug 121822 so when the first downloadable
daily build with a fix included is available then I can use it to test this bug
also.

I am very confident that this bug can be verified fixed this way because there
are multiple more involved scenarios that I can use in addition to the testcase.

Let's hope that the work that you did fixes both.

Thanks and good luck.

Comment 32

[Marc Attinasi]

The patch was checked in yesterday - can somebody check this bug with one of
today's (or later) builds?

Comment 33

[bht237]

Congratulations! The latest build passed the testcase.

However I cannot get into the sites on which this testcase is based because of
bug 125003. I am not allowed to close this issue for that reason.

I will do my best to promote bug 125003 (it already has a testcase) so that it
does not block this one.

Comment 34

[Marc Attinasi]

Marking FIXED: if the site on which the testcase is based still has problems,
then reopen or ope a new bug.  Thansk for checking the testcase for me!

Comment 35

[bht237]

I am afraid it's back (or it was never a duplicate of bug 121822 as we thought).
Today is the first day I could test this on a real world site due to completion
of bug 125003. Haven't tried the testcase yet.
Talkback ID: TB36336660E
This Talkback thing is great. I am glad it is included in the build:
2002031708

Comment 36

[Boris Zbarsky [:bzbarsky]]

stephend, could you get the stack?  TB36336660E

Comment 37

[Marc Attinasi]

I cannot find that talkback ID - Searching for a report by the email address I
find only talkback 4156951 filed on the 17th.  The stack for that talkback is:

     nsDOMWindowList::GetLength  
[d:\builds\seamonkey\mozilla\dom\src\base\nsDOMWindowList.cpp, line 107]
     GlobalWindowImpl::GetLength
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 1699]
     XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
     XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2027]
     XPC_WN_GetterSetter
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1299]
     js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 790]
     js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 881]
     js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 2503]
     js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2578]
     js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 806]
     nsXPCWrappedJSClass::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 1195]
     nsXPCWrappedJS::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 430]
     PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 117]
     SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 139]
     nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1218]
     nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1737]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3457]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
     nsXULElement::HandleChromeEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 4680]
     GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 687]
     nsDocument::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3231]
     nsEventStateManager::PreHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 487]
     PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6051]
     PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5979]
     nsViewManager::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2043]
     nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 306]
     nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1863]
     HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
     nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 869]
     nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 886]
     nsWindow::DispatchFocus
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4903]
     nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3734]
     nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1131]
     KERNEL32.DLL + 0x3663 (0xbff73663)  
     KERNEL32.DLL + 0x22894 (0xbff92894)  

which is totally different :(

bht, where did you get the talkback ID?  Did you file another different talkback
on the same day, for another crash?

Comment 38

[bht237]

Marc, I am so sorry.
TB36336660E is is Netscape 6.10 not Mozilla.
4156951, the one you copied is correct.

Don't be sad it's a different crash from what you expected. I'll do what I can
to help debug this. I have to tell you though that the testcase does not produce
this error. Can you patch this from the stack trace alone? That would be really
good so I can download a build and re-test.
Writing a testcase for this was really, really difficult and it had the tendency
to slip away when reduced in complexity.
Users get this when they want to go back from a secure form back and forth
between their shopping cart and the secure order form - so I am really under
pressure with this - I hope you understand.

Comment 39

[Marc Attinasi]

From that stack alone all I can say is that this is a totally different bug.  I
do not doubt that it happens in the same or similar situations or sequence of
operations, but it has looks like it is totally outside of layout this time.

I think it is best to open a new bug on the one talkback and try to find the
correct owner, who can decipher that stack.  And we need to refer to this bug
too just to make sure that any pertinent information herein is available to the
new owner.

bht - can you open the new bug or describe here what you did to cause it so I
can open it for you?

Comment 40

[bht237]

I opened bug 131841 for this. Please help to lift the urgency of the new bug.
This one has already suffered a lot because of other dependencies.

Comment 41

[Marc Attinasi]

OK, I'll do what I can on the other bug.  The best way, of course, is to get a
reproducable scenario or testcase, or a load of talkbacks.

Closing this one back out.  Thanks bht!

Comment 42

[bht237]

Marc,
I have 4 different talkback incidents and one new testcase in the other bug now.
The process took me a full day. It was a very stressful job and I am exhausted.
I hope that Mozilla will get the benefits from this soon. After the experience
with this bug, I wouldn't be surprised if the new bug is not the last one in
this particular spot that I hit.
Maybe you can help?

Comment 43

[bht237]

Marc,
May I once again come back to your kind offer to help with the new bug 131841?
It has a new additional reproducible testcase now and plenty of stacktraces.
What it needs is a secure server to host the testcase because the simple
verisign site does no longer do the job.
I have been trying hard to get a secure server to host the testcase but no luck.
Can you help or do you know of anyone who could?

Comment 44

[Chris Petersen]

Marking verified in the April 23rd build (2002-04-23-06) under Windows ME.