Closed Bug 7858 Opened 25 years ago Closed 25 years ago

Recursion crash using sNetSupportDialog::ConfirmCheck

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: solomonr, Assigned: danm.moz)

References

(
URL
)

Details

(Whiteboard: [DEPENDENCY] 7457 is now fixed -- the bad thing form entry fields are not sticking) 

To recreate the error:
From www.stockpoint.com enter a ticker symbol, click on quick graph, change any
of the parameters, chose go. Wallet comes up , click ok and then the page fault
occurs:

APPRUNNER caused an invalid page fault in
module NSAPPSHELL.DLL at 0177:00c93b14.
Registers:
EAX=00000000 CS=0177 EIP=00c93b14 EFLGS=00010246
EBX=00000000 SS=017f ESP=0076e2e4 EBP=0076e304
ECX=00d815e0 DS=017f ESI=00000000 FS=0cd7
EDX=00000002 ES=017f EDI=064b7190 GS=0000
Bytes at CS:EIP:
8b 06 ff 50 04 c7 47 24 01 00 00 00 83 7f 24 01
Stack dump:
00000000 80000000 80000000 00c9198b 00000000 00000000 064a7870 06522820 0076e33c
00c93ac6 064b7190 00c919d1 064b7190 064a7a34 064a7a30 00000000
Assignee: don → morse
Component: Apprunner → other
Status: NEW → ASSIGNED
Assignee: morse → davidm
Status: ASSIGNED → NEW
First thing I did was generate a greatly-simplified test case.  It is shown
below.  The steps for recreating the error are:

1. Bring up a page containing the HTML shown below
2. Click on either the "X" or "Y" select list
3. Click on the rightmost "Go" button
4. A wallet dialog appears asking if you want to save the form
5. Click either OK or CANCEL in this dialog
6. Crash occurs with stack trace shown at end of this message

What I have discovered is that the call that I am making to display the wallet
dialog (namely nsNetSupportDialog::ConfirmCheck) is being done recursively.  I
set a breakpoint on this routine and below is the stacktrace at the time of the
second entry.  I don't know why this recursion is occurring but I'm sure that
this is the cause of the problem.

To verify that the recursion is causing the problem, I put some code at the
point at which I call the dialog to check to see if I have been entered
recursively; if so I exit without calling the dialog.  This "band-aid" solution
indeed solved the problem for my simpified test case.  But when I then tried the
original example, it still crashed even with my "band-aid".

Some observations.  From the stack I notice that entry into my routine is being
triggered by a mouse event.  And, indeed, the recursion is occurring because
after I have called the dialog, another mouse event is triggering and calling my
routine again.  That explains why step 2 (click on select list) is necessary --
it produces the mouse events that cause the recursion.  If you skip step 2,
there is no recursion and no crash.

Another interesting point is that if you press the leftmost "Go" button, there
is no recursion and no crash.  This I have no explaination for.  The difference
between these two buttons is that one is of type IMAGE and the other of type
SUBMIT.  The image is being fetched from a server but I don't know if that has
any relevance.

I think I've taken this about as far as I can.  The problem appears to be lower
than wallet; it is in the dialog routine itself from which the recursion is
occurring.  So I'm assigning this to davidm.  David, let me know if I can be of
any assistance to you.  The wallet code that is calling the dialog is in
extensions/wallet/src/wallet.cpp.

-------------------------------

SIMPLIFIED TEST CASE

<HTML>
  <BODY>
    <FORM>
      <INPUT TYPE=TEXT NAME=sym3 SIZE=5>
      <INPUT TYPE=TEXT NAME=sym4 SIZE=5>
      <INPUT TYPE=TEXT NAME=sym5 SIZE=5>
      <SELECT NAME="sym6">
        <OPTION>X</OPTION>
      </SELECT>
      <SELECT NAME="sym8">
        <OPTION>Y</OPTION>
      </SELECT>
      <INPUT TYPE=SUBMIT Value="Go">
      <INPUT TYPE=IMAGE SRC="http://images.neural.com/stockpoint/go.gif">
    </FORM>
  </BODY>
</HTML>

------------------------------------

STACK TRACE UPON RECURSIVE ENTRY INTO nsNetSupportDialog::ConfirmCheck

nsNetSupportDialog::ConfirmCheck(nsNetSupportDialog * const 0x026cc4a0, const
nsString & {...}, const nsString & {...}, int * 0x0012c69c, int * 0x0012c6e0)
line 340
Wallet_CheckConfirm(char * 0x026d2550, char * 0x026c48d0, int * 0x0012c6e0) line
428
WLLT_OKToCapture(int * 0x0012cfd8, int 3, char * 0x026cf250) line 2168 + 17
bytes
nsWalletlibService::WALLET_OKToCapture(nsWalletlibService * const 0x01342ef0,
int * 0x0012cfd8, int 3, char * 0x026cf250) line 78 + 17 bytes
nsFormFrame::ProcessAsURLEncoded(int 0, nsString & {...}, nsIFormControlFrame *
0x029ae848) line 771
nsFormFrame::OnSubmit(nsFormFrame * const 0x029ad5a0, nsIPresContext *
0x026b17e0, nsIFrame * 0x029ae7a0) line 463
nsImageControlFrame::MouseClicked(nsIPresContext * 0x026b17e0) line 389
nsImageControlFrame::HandleEvent(nsImageControlFrame * const 0x029ae7a0,
nsIPresContext & {...}, nsGUIEvent * 0x0012de84, nsEventStatus &
nsEventStatus_eIgnore) line 257
PresShell::HandleEvent(PresShell * const 0x029a1254, nsIView * 0x029b94f0,
nsGUIEvent * 0x0012de84, nsEventStatus & nsEventStatus_eIgnore) line 2026 + 38
bytes
nsView::HandleEvent(nsView * const 0x029b94f0, nsGUIEvent * 0x0012de84, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 833
nsView::HandleEvent(nsView * const 0x029a8bf0, nsGUIEvent * 0x0012de84, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x029a68f0, nsGUIEvent * 0x0012de84, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x029a6820, nsGUIEvent * 0x0012de84, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x029a0630, nsGUIEvent * 0x0012de84, unsigned
int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsViewManager::DispatchEvent(nsViewManager * const 0x029a0f20, nsGUIEvent *
0x0012de84, nsEventStatus & nsEventStatus_eIgnore) line 1737
HandleEvent(nsGUIEvent * 0x0012de84) line 67
nsWindow::DispatchEvent(nsWindow * const 0x029b9914, nsGUIEvent * 0x0012de84,
nsEventStatus & nsEventStatus_eIgnore) line 417 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012de84) line 438
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3012 +
15 bytes
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long -1, long *
0x0012e024) line 2374 + 24 bytes
nsWindow::WindowProc(void * 0x08aa0480, unsigned int 514, unsigned int 0, long
-1) line 480 + 27 bytes
USER32! 77e71e3b()
USER32! 77e89eda()
USER32! 77e76569()
USER32! 77e7288d()
USER32! 77e72918()
nsWindow::WindowProc(void * 0x08aa0480, unsigned int 8, unsigned int 34997212,
long 0) line 492
USER32! 77e71ab7()
USER32! 77e71a77()
NTDLL! 77f7624f()
USER32! 77e7288d()
USER32! 77e72918()
nsWindow::WindowProc(void * 0x021603dc, unsigned int 6, unsigned int 1, long
77857968) line 492
USER32! 77e71ab7()
USER32! 77e71a77()
NTDLL! 77f7624f()
nsWebShellWindow::Show(nsWebShellWindow * const 0x026ccbd0, int 1) line 1307
nsAppShellService::CreateDialogWindow(nsAppShellService * const 0x01007190,
nsIWebShellWindow * 0x00000000, nsIURL * 0x026cc790, int 1, nsIWebShellWindow *
& 0x026ccbd0, nsIStreamObserver * 0x00000000, nsIXULWindowCallbacks *
0x026cc4a4, int 300, int 200) line 523
nsAppShellService::RunModalDialog(nsAppShellService * const 0x01007190,
nsIWebShellWindow * 0x00000000, nsIURL * 0x026cc790, nsIWebShellWindow * &
0x026ccbd0, nsIStreamObserver * 0x00000000, nsIXULWindowCallbacks * 0x026cc4a4,
int 300, int 200) line 557 + 42 bytes
nsNetSupportDialog::DoDialog(nsString & {...}) line 444
nsNetSupportDialog::ConfirmCheck(nsNetSupportDialog * const 0x026cc4a0, const
nsString & {...}, const nsString & {...}, int * 0x0012e448, int * 0x0012e48c)
line 348
Wallet_CheckConfirm(char * 0x026c9550, char * 0x026cc430, int * 0x0012e48c) line
428
WLLT_OKToCapture(int * 0x0012ed84, int 3, char * 0x026c5810) line 2168 + 17
bytes
nsWalletlibService::WALLET_OKToCapture(nsWalletlibService * const 0x01342ef0,
int * 0x0012ed84, int 3, char * 0x026c5810) line 78 + 17 bytes
nsFormFrame::ProcessAsURLEncoded(int 0, nsString & {...}, nsIFormControlFrame *
0x029ae848) line 771
nsFormFrame::OnSubmit(nsFormFrame * const 0x029ad5a0, nsIPresContext *
0x026b17e0, nsIFrame * 0x029ae7a0) line 463
nsImageControlFrame::MouseClicked(nsIPresContext * 0x026b17e0) line 389
nsImageControlFrame::HandleEvent(nsImageControlFrame * const 0x029ae7a0,
nsIPresContext & {...}, nsGUIEvent * 0x0012fc30, nsEventStatus &
nsEventStatus_eIgnore) line 257
PresShell::HandleEvent(PresShell * const 0x029a1254, nsIView * 0x029b94f0,
nsGUIEvent * 0x0012fc30, nsEventStatus & nsEventStatus_eIgnore) line 2026 + 38
bytes
nsView::HandleEvent(nsView * const 0x029b94f0, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 833
nsView::HandleEvent(nsView * const 0x029a8bf0, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x029a68f0, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x029a6820, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x029a0630, nsGUIEvent * 0x0012fc30, unsigned
int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsViewManager::DispatchEvent(nsViewManager * const 0x029a0f20, nsGUIEvent *
0x0012fc30, nsEventStatus & nsEventStatus_eIgnore) line 1737
HandleEvent(nsGUIEvent * 0x0012fc30) line 67
nsWindow::DispatchEvent(nsWindow * const 0x029a7744, nsGUIEvent * 0x0012fc30,
nsEventStatus & nsEventStatus_eIgnore) line 417 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fc30) line 438
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3012 +
15 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line
3161
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 1573222, long *
0x0012fdec) line 2374 + 24 bytes
nsWindow::WindowProc(void * 0x041d0464, unsigned int 514, unsigned int 0, long
1573222) line 480 + 27 bytes
USER32! 77e71250()

------------------------------------

STACK TRACE AT TIME OF CRASH

nsWebShellWindow::ShowModalInternal(nsWebShellWindow * const 0x026c5d70) line
1334 + 3 bytes
nsWebShellWindow::ShowModal(nsWebShellWindow * const 0x026c5d70) line 1314 + 9
bytes
nsAppShellService::RunModalDialog(nsAppShellService * const 0x01007190,
nsIWebShellWindow * 0x00000000, nsIURL * 0x026cc790, nsIWebShellWindow * &
0x026c5d70, nsIStreamObserver * 0x00000000, nsIXULWindowCallbacks * 0x026cc4a4,
int 300, int 200) line 568
nsNetSupportDialog::DoDialog(nsString & {...}) line 444
nsNetSupportDialog::ConfirmCheck(nsNetSupportDialog * const 0x026cc4a0, const
nsString & {...}, const nsString & {...}, int * 0x0012e448, int * 0x0012e48c)
line 348
Wallet_CheckConfirm(char * 0x026c9550, char * 0x026cc430, int * 0x0012e48c) line
428
WLLT_OKToCapture(int * 0x0012ed84, int 3, char * 0x026c5810) line 2168 + 17
bytes
nsWalletlibService::WALLET_OKToCapture(nsWalletlibService * const 0x01342ef0,
int * 0x0012ed84, int 3, char * 0x026c5810) line 78 + 17 bytes
nsFormFrame::ProcessAsURLEncoded(int 0, nsString & {...}, nsIFormControlFrame *
0x029ae848) line 771
nsFormFrame::OnSubmit(nsFormFrame * const 0x029ad5a0, nsIPresContext *
0x026b17e0, nsIFrame * 0x029ae7a0) line 463
nsImageControlFrame::MouseClicked(nsIPresContext * 0x026b17e0) line 389
nsImageControlFrame::HandleEvent(nsImageControlFrame * const 0x029ae7a0,
nsIPresContext & {...}, nsGUIEvent * 0x0012fc30, nsEventStatus &
nsEventStatus_eIgnore) line 257
PresShell::HandleEvent(PresShell * const 0x029a1254, nsIView * 0x029b94f0,
nsGUIEvent * 0x0012fc30, nsEventStatus & nsEventStatus_eIgnore) line 2026 + 38
bytes
nsView::HandleEvent(nsView * const 0x029b94f0, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 833
nsView::HandleEvent(nsView * const 0x029a8bf0, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x029a68f0, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x029a6820, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x029a0630, nsGUIEvent * 0x0012fc30, unsigned
int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsViewManager::DispatchEvent(nsViewManager * const 0x029a0f20, nsGUIEvent *
0x0012fc30, nsEventStatus & nsEventStatus_eIgnore) line 1737
HandleEvent(nsGUIEvent * 0x0012fc30) line 67
nsWindow::DispatchEvent(nsWindow * const 0x029a7744, nsGUIEvent * 0x0012fc30,
nsEventStatus & nsEventStatus_eIgnore) line 417 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fc30) line 438
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3012 +
15 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line
3161
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 1573222, long *
0x0012fdec) line 2374 + 24 bytes
nsWindow::WindowProc(void * 0x041d0464, unsigned int 514, unsigned int 0, long
1573222) line 480 + 27 bytes
USER32! 77e71250()
Summary: page fault error → page fault error - causes crash
Crasher.  Can this get in for M7, or ya want to release note it?
It would be a bummer not to get this fixed for M7.  I have some more information
that might help.  I'll post it below.
David,

If I add the "band-aid" code that I referred to above, I get a crash with a
stacktrace that doesn't even contain either your dialog code or my code which
calls your code.  But it definitely contains mouse-event code.  The trace is
below.

My uninformed guess is that we should probably be flushing out all mouse events
when the dialog starts.  I guess the flushing could be done either in my code
before it calls the dialog or probably at the head of the dialog itself so that
other callers can also benefit.  I have no idea how to do such flushing -- do
you?

If you want to try out my band-aid (recall the band-aid is simply that I detect
a recursive entry into my code and, if so, I don't call for a recursive dialog),
the changes are as follows:

mozilla/extensions/wallet/src/wallet.cpp:

***************
*** 2147,2152 ****
--- 2147,2153 ----
  PUBLIC void
  WLLT_OKToCapture(PRBool * result, PRInt32 count, char* urlName) {
    nsAutoString * url = new nsAutoString(urlName);
+   static int level = 0;

    /* see if this url is already on list of url's for which we don't want to
capture */
    wallet_InitializeURLList();
***************
*** 2160,2165 ****
--- 2161,2172 ----
      }
    }

+   if (level > 0) {
+     *result = PR_FALSE;
+     return;
+   }
+   level++;
+
    /* ask user if we should capture the values on this form */
    if (wallet_GetFormsCapturingPref() && (count>=3)) {
      char * message = Wallet_Localize("WantToCaptureForm?");
***************
*** 2181,2186 ****
--- 2188,2194 ----
    } else {
      *result = PR_FALSE;
    }
+   level--;
  }

  /*

And here's the stack trace mentioned above.

NTDLL! 77f76148()
nsDebug::Assertion(char * 0x00499e20, char * 0x00499e10, char * 0x00499de4, int
1151) line 146 + 13 bytes
NS_MakeAbsoluteURL(nsIURL * 0x00000000, const nsString & {...}, const nsString &
{...}, nsString & {...}) line 1151 + 32 bytes
nsFormFrame::OnSubmit(nsFormFrame * const 0x02915a10, nsIPresContext *
0x02a3baf0, nsIFrame * 0x026e7e20) line 498 + 28 bytes
nsImageControlFrame::MouseClicked(nsIPresContext * 0x02a3baf0) line 389
nsImageControlFrame::HandleEvent(nsImageControlFrame * const 0x026e7e20,
nsIPresContext & {...}, nsGUIEvent * 0x0012fc30, nsEventStatus &
nsEventStatus_eIgnore) line 257
PresShell::HandleEvent(PresShell * const 0x028e1824, nsIView * 0x02a75ab0,
nsGUIEvent * 0x0012fc30, nsEventStatus & nsEventStatus_eIgnore) line 2026 + 38
bytes
nsView::HandleEvent(nsView * const 0x02a75ab0, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 833
nsView::HandleEvent(nsView * const 0x02901660, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x028ff6a0, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x028ff3b0, nsGUIEvent * 0x0012fc30, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x028e1d30, nsGUIEvent * 0x0012fc30, unsigned
int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsViewManager::DispatchEvent(nsViewManager * const 0x028e0420, nsGUIEvent *
0x0012fc30, nsEventStatus & nsEventStatus_eIgnore) line 1737
HandleEvent(nsGUIEvent * 0x0012fc30) line 67
nsWindow::DispatchEvent(nsWindow * const 0x02900aa4, nsGUIEvent * 0x0012fc30,
nsEventStatus & nsEventStatus_eIgnore) line 417 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fc30) line 438
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3012 +
15 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line
3161
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 13238448, long *
0x0012fdec) line 2374 + 24 bytes
nsWindow::WindowProc(void * 0x06b8044c, unsigned int 514, unsigned int 0, long
13238448) line 480 + 27 bytes
USER32! 77e71250()
Component: other → XPApps
Priority: P3 → P1
Summary: page fault error - causes crash → Recursion crash using sNetSupportDialog::ConfirmCheck
Target Milestone: M7
David, can we actually fix this now?
I haven't had a chance to look at the bug. It might be an XPToolkit bug if Steves
idea of event flushing is the correct solution. We definitely should not be
recursing like this. I just hope I can reproduce on my mac.
QA Contact: leger → beppe
Component: XPApps → XP Toolkit/Widgets
On the mac it doesn't recurse but none of the passed in text draws. Assigning to
danm and changing component to XPToolkit
Assignee: davidm → danm
Status: NEW → RESOLVED
Closed: 25 years ago
Component: XP Toolkit/Widgets → XPApps
Resolution: --- → FIXED
The stacked double modal dialog was interacting in bad ways with the nsNetSupportDialog's
attempts to retain a pointer to the current modal dialog.  I feel I should point out that this
was all in code written by the guy who assigned this bug to me.  So I've changed the component
back to XPApps after fixing the crash.

Note that the interesting problem of the double mousedown (which eventually generates a modal
dialog) still remains.  I've adjusted things so this situation no longer causes a crash, but the two
dialogs are still created.  I've generated a new bug 8263 to track that problem.

Thanks, morse, for generating the simple test case.  It helped a lot.
Status: RESOLVED → VERIFIED
using the 1999061708 build, the app does not crash, marking verified.
Status: VERIFIED → REOPENED
Depends on: 8383
Target Milestone: M7 → M8
Reopened -- a fix entered for bug 8383 on 17 June reverted the fix for this bug.
You're right, my fix for 8383 did break this again.  Don't understand that
because I tested it out after I made my fix and I thought it was working then.
But it definitely is crashing now.

In any case, the original fix made here was wrong because it introduced 8383.
And the reason that happened is described in the 8383 report.

Basically, the RunModalDialog routine has a side effect of updating one of its
arguments.  But other threads are expecting that the updating occurs before the
dialog actually starts.  This is really bad coding practice.  What should have
been done here is to have two separate routines -- one that updates the argument
and the other that produces the dialog.  That would certainly still satisfy bug
8383 and possibly fix up this problem as well (I say possibly because I don't
really understand that factors that were causing this problem).

In any event, this is davidm's code so should the bug be assigned to him?
My opinion is that the bug is NOT in my code. It is in the code which is bring up
the window twice. I don't see how that be my codes fault but if I am wrong feel
free to point out what I am doing wrong.
OK, I think I understand.  The reason for this crash is the recursion as davidm
just reminded me.  And in that recursion we probably destroy the argument to
RunModalDialog because it is a global.  Had the argument been local to the
caller, it would not get destroyed by the recursion and that is what danm's fix
accomplished.  But by making it local, we lose the ability for other threads
to test it and so get bug 8383.

This means that the subdivision into two routines, although cleaner coding,
won't solve this problem.

Yes, I agree the bug is in the fact that the recursion is occuring in the first
place and none of us have any idea of why that is happening.
Here's a horrible thought.  We could probably solve both problems if we made the
global argument be a stack instead of a single variable.  That way we could
support the recursion and also allow other threads to see the value.

I'm not proposing that we do this but I think it will work.  What we should do
is find out where the recursion is coming from and fix that.  But this is
certainly a last-resort solution.
Resolution: FIXED → ---
Clearing Fixed resolution since the bug is now Reopened.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
While arguably this bug is the fault of the code that brings up the window twice,
that's not going to be fixed any time soon.  I've reworked things a bit and I claim
it's fixed once again, this time hopefully without busting bug 8383.
Depends on: 7457
Whiteboard: [DEPENDENCY] this bug cannot be verified until 7457 is fixed
Just an update for all of you, I reopened bug 7457, apprunner does not interact
with asp
Whiteboard: [DEPENDENCY] this bug cannot be verified until 7457 is fixed → [DEPENDENCY] 7457 is now fixed -- the bad thing form entry fields are not sticking
Status: RESOLVED → VERIFIED
just verified that this now works, using 1999080908 on win98
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.