alert windows are empty.



MailNews Core
19 years ago
10 years ago


(Reporter: laurel, Assigned: Dan M)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: difficult to reproduce. may be fixed.)



19 years ago
Using 1999060808 linux rh5.2
Doesn't happen using jun8 build NT 4.0 or Mac OS 8.51

After sending a mail message (also see bug #7478 and #7417 -- must resise
compose window in order to user in the first place) the compose window goes
blank and stays around -- must be manually closed.


19 years ago
QA Contact: lchiang → laurel


19 years ago
Assignee: rhp → ducarroz

Comment 1

19 years ago
Could this be an apprunner type problem?

- rhp


19 years ago
Hardware: HP → PC

Comment 2

19 years ago
Needs to be fixed for M7 - to the user, it appears to be some hang and the user
isn't sure that the message gets sent.

(Correcting platform to PC since Linux runs on PCs)

Comment 3

19 years ago
Curiously, this isn't happening today using the same jun8 build.  It was
happening to several of us in the group yesterday, it continued for me ALL day
yesterday and now it's not happening.  Just some info for the record.

Comment 4

19 years ago
Update using 1999061013 on linux rh5.2:
I'm seeing a problem with the compose window only when sending using a multiple
accounts prefs file.  If I switch to single pop for same (main) user, I can send
and get messages okay.

Upon send with multiple accounts I see the compose window go blank, a second
blank (compose?) window appears and both blank windows linger and must be closed
manually.  Message does not get sent.


19 years ago
Severity: normal → critical
Summary: [PP] Mail compose window goes blank and lingers after Send. → [PP] Send not occurring: Mail compose window goes blank and lingers after Send.


19 years ago
Target Milestone: M7
Seth, Are you able to reproduce the problem?
I'm able to reproduce the problem.

here is what I am seeing:

on linux, after I send an email, the compose window goes away and small, blank
alert pops up.  I've stepped through the debugger, and here is what I find.

rhp's code calls nsMsgDisplayMessageByString() with

This eventually calls into nsNetSupportDialog::Alert().

Alert() eventually calls nsAppShellService::RunModalDialog()

 561     nsresult gotParent;
 562     gotParent = aParent ?
aParent->GetWidget(*getter_AddRefs(parentWindowWidgetThing)) :
 563                           NS_ERROR_FAILURE;
 564     // Windows OS wants the parent disabled for modality
 565     if (NS_SUCCEEDED(gotParent))
 566       parentWindowWidgetThing->Enable(PR_FALSE);
 567     aResult->ShowModal();
 568     if (NS_SUCCEEDED(gotParent))
 569       parentWindowWidgetThing->Enable(PR_TRUE);

On linux, NS_SUCCEEDED(gotParent) is not TRUE.  davidm, is that a problem?

That code in nsAppShellService::RunModalDialog() is prefixed and postfixed with
some code hidden behind #ifdef XP_PC.

Eventually, we call into nsWebShellWindow::ShowModalInternal()

and we stay in this loop forever:

1385   while (NS_SUCCEEDED(rv) && mContinueModalLoop == PR_TRUE) {
1386     void      *data;
1387     PRBool    isRealEvent,
1388               processEvent;
1390     rv = subshell->GetNativeEvent(isRealEvent, data);
1391     if (NS_SUCCEEDED(rv)) {
1392       subshell->EventIsForModalWindow(isRealEvent, data, window,
1393       if (processEvent == PR_TRUE)
1394         subshell->DispatchNativeEvent(isRealEvent, data);
1395     }
1396   }

I get a similar behaviour after I post to news on Linux.

On Linux, doing a delete message of a news message (in effect a cancel) uses the
Alert() code, and it seems to work.

davidm, can you help here?
I should add, that even though all this happens, the message does get sent.

If we don't find a fix, we could turn off rhp's call in nsMsgSend.cpp to
nsMsgDisplayMessageByString().  at least that way, the app is usable on linux
until we find a fix.

Comment 8

19 years ago
Hmm, Laurel says the message isn't getting sent.  Perhaps it has to do with when
the compose window gets closed manually?
actually, laurel and I have different builds.  My is up to date (as of June
10th, 7 pm.)

jfd and rhp have landed changes today.

Comment 10

19 years ago
I don't know how the internals of modal dialogs work. You might want to ask danm.
As these dialogs don't have a parent window I would have expected them all to
never work but I know that at one point in time the user/password dialog worked
on all 3 platforms.
	I have seen the small blank dialog when for some reason PLEvents don't get
proprogated until after the window gets destroyed. If you have a working Linux
build I would be happy to suggest a couple of places where breakpoints would tell
us a lot more about what is really going on.
adding danm to cc list.

keep in mind, that we are using Alerts(), not PromptUserAndPassword() or other

And Alert() does work from other places.  (message cancel).
we are calling Alert() from netlib.

perhaps the thread is blocking, at this prevents the xul (for the alert) from
getting loaded?

#0  nsNetSupportDialog::Alert (this=0x84a1668, aText=@0xbfffef10) at
#1  0x40a7a528 in nsMsgDisplayMessageByString (msg=0xbfffef84 "Message
[dafadsfa] sent successfully!") at nsMsgPrompts.cpp:65
#2  0x40a6a625 in nsMsgComposeAndSend::DeliverAsMailExit (this=0x8570460,
aUrl=0x856f2c0, aExitCode=0) at nsMsgSend.cpp:3039
#3  0x40a68631 in MailDeliveryCallback (aUrl=0x856f2c0, aExitCode=0,
tagData=0x8570460) at nsMsgSend.cpp:1605
#4  0x40a703fc in nsMsgDeliveryListener::OnStopRunningUrl (this=0x856f258,
aUrl=0x856f2c0, aExitCode=0) at nsMsgDeliveryListener.cpp:58
#5  0x409ff3f6 in nsUrlListenerManager::BroadcastChange (this=0x856f530,
aUrl=0x856f2c0, notification=nsUrlNotifyStopRunning, aErrorCode=0) at
#6  0x409ff468 in nsUrlListenerManager::OnStopRunningUrl (this=0x856f530,
aUrl=0x856f2c0, aErrorCode=0) at nsUrlListenerManager.cpp:97
#7  0x40a60088 in nsSmtpUrl::SetUrlState (this=0x856f2c0, aRunningUrl=0,
aExitCode=0) at nsSmtpUrl.cpp:173
#8  0x40a63f66 in nsSmtpProtocol::ProcessProtocolState (this=0x856f630,
url=0x856f2c0, inputStream=0x852dc48, length=36) at nsSmtpProtocol.cpp:1385
#9  0x40a3f7ef in nsMsgProtocol::OnDataAvailable (this=0x856f630,
aURL=0x856f2c0, aIStream=0x852dc48, aLength=36) at nsMsgProtocol.cpp:142
#10 0x402ba4a4 in nsStreamListenerProxy::OnDataAvailable (this=0x856fbb8,
aURL=0x856f2c0, aIStream=0x852dc48, aLength=36) at nsNetThread.cpp:815
#11 0x402bf937 in stub_put_block (stream=0x85d6f60, buffer=0x80a4c80 "250
Message received:
STARTTLS\r\n#FFFFFF\">\n&nbsp;\n<br>&nbsp;\n<table BORDER COLS=1 WIDTH=\"100%\"
BGCOLOR=\"#FFFFAA\" >\n<tr>\n<td>\n<center>"..., length=36) at
#12 0x40262a25 in net_MemCacheWrite (stream=0x85d5688, buffer=0x80a4c80 "250
Message received:
STARTTLS\r\n#FFFFFF\">\n&nbsp;\n<br>&nbsp;\n<table BORDER COLS=1 WIDTH=\"100%\"
BGCOLOR=\"#FFFFAA\" >\n<tr>\n<td>\n<center>"..., len=36) at mkmemcac.c:660
#13 0x401d4a0e in net_flush_sockstub_data (ce=0x8493f98) at sockstub.cpp:434
#14 0x401d4ced in net_ProcessSockStub (ce=0x8493f98) at sockstub.cpp:544
#15 0x4028eed7 in NET_ProcessNet (ready_fd=0x839b058, fd_type=2) at
#16 0x40296e65 in NET_PollSockets () at mkselect.c:320
#17 0x402b8d92 in nsNetlibService::NetPollSocketsCallback (aTimer=0x85d7c40,
aClosure=0x80a3778) at nsNetService.cpp:1244
#18 0x40135f05 in ?? () from
#19 0x40136382 in ?? () from
#20 0x4069cc11 in ?? () from /usr/lib/
#21 0x4069bdd2 in ?? () from /usr/lib/
#22 0x4069c3bb in ?? () from /usr/lib/
#23 0x4069c571 in ?? () from /usr/lib/
#24 0x405c215b in ?? () from /usr/lib/
#25 0x400e0009 in ?? () from
#26 0x40021791 in nsAppShellService::Run (this=0x809ab78) at
#27 0x804b9e8 in main (argc=2, argv=0xbffffa04) at nsAppRunner.cpp:571

I'm going to turn off rhp's code to throw up the dialog on success until we can
figure this out.


19 years ago
Assignee: ducarroz → sspitzer
The dialog is displayed after the send, therefore the message should have been
already fully sent. As it a UNIX only problem I am reassigning this bug to

Comment 14

19 years ago
It doesn't appear to be the nspr PLEventQueue blocking problem that I know and
love. My guess is that netlib is stalled because either it isn't getting called
or has some flag to prevent reentrancy. I would suggest point a break point in
NET_ProcessNet to see if netlib is ever getting called to load in the XUL file.

Comment 15

19 years ago
Updated info using 1999061109 m7 on linux rh5.2:
An alert dialog is still displaying after clicking Send.  Compose dialog goes
away, but message is not sent. If you close the alert dialog, a crash occurs.

Updated info using 1999061108 m7 on NT 4.0:
An alert dialog is now appearing after clicking Send. Compose dialog goes away,
but message is not sent. Able to close the alert dialog without crash.

Mac doesn't exhibit this same problem using 1999061108 m7.
laurel, can you add what the alert message is (on windows, since linux is


Comment 17

19 years ago
Here's the description of the windows alert dialog I'm seeing:
! [StringID -2142568447?]
There is an OK button in the dialog, which works to dismiss the dialog, but the
message isn't sent.

Also, let me confirm that I'm the only one seeing this behavior either on linux
or windows.

Comment 18

19 years ago
FYI: Build 1999061108M7 on Win32/NT4, 1999061109M7 on Linux

Summary: I was able to send a message from NT4 and Linux.

Win32/NT4: Had 1 pop account and was able to send a message. Also used 4
accounts (2pop, 2imap) and was able to send from one of the pop accounts.
Noticed that the Compose window closed immediately.

Linux: Had 1 pop account and was able to send a message. Also used 4 accounts
(2pop, 2imap) and was able to send from one of the pop accounts. Noticed that
the Compose window closed immediately without an alert dialog appearing.
Summary: [PP] Send not occurring: Mail compose window goes blank and lingers after Send. → [PP] alert problem on Linux
changing summary.

the real problem is that alerts on Linux (and possibly mac) never seem to load
the alert xul.
danm, does this sound like a duplicate of one of your bugs?

who is working on alerts / modal dialogs for linux?  (mcafee / syd?)
Assignee: sspitzer → danm


19 years ago
Target Milestone: M7 → M8

Comment 22

19 years ago
moving to m8. danm, let me know if you get somthing..


19 years ago
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 23

19 years ago
I'm having a very hard time figuring out exactly what is the complaint behind this bug report.
It seems to start off talking about the composer window not actually closing, and then move on
to a discussion of how modal dialogs work, and finally settle on an anomalous alert window
popping up.  If there are really multiple problems described in this bug report, I'd appreciate
someone separating them into short, concise, separate bugs.

So I just tried it, hoping for elucidation.  It was with a build from source pulled from
the closed  tree this morning, 16 June, the day after the tree closed for M7.  I didn't notice any
of these problems.  I composed two messages in a row and "sent" them.  They never showed up
in *my* mailbox, but the compose window did close, and I noticed no strange alerts.

I think it's been fixed, whatever the problem was.  If it's still a problem for someone else, please
post exact instructions.

Comment 24

19 years ago
I believe that the code is turned off. On windows when you send a message you get
an alert saying message sent. On linux the same dialog would display a window
frame but it's content would never be loaded. I am sure sspitzer can tell you
what needs to be done to turn the code back on.
davidm is right, the code has been turned off with ifdefs.

To reproduce:

add this line to mozilla/mailnews/base/public/msgCore.h

#define BUG_7770_FIXED 1

no you should be able to reproduce the bug on linux by:

sending an email
cancelling a news message

If you are having problems configuring 5.0 to read / send mail & news, I'll
gladly come to your cube and configure it for you.

Or you can read

/mailnews/compose/src/nsMsgPrompts.cpp, line 43 -- #if defined(BUG_7770_FIXED)
/mailnews/compose/src/nsMsgPrompts.cpp, line 71 -- #if defined(BUG_7770_FIXED)
/mailnews/news/src/nsNNTPProtocol.cpp, line 3726 -- #if defined(BUG_7770_FIXED)
|| defined(XP_PC)
/mailnews/news/src/nsNNTPProtocol.cpp, line 3730 -- #endif /* BUG_7770_FIXED */
/mailnews/news/src/nsNNTPProtocol.cpp, line 3750 -- #if defined(BUG_7770_FIXED)
|| defined(XP_PC)
/mailnews/news/src/nsNNTPProtocol.cpp, line 3755 -- #endif /* BUG_7770_FIXED */
/mailnews/news/src/nsNNTPProtocol.cpp, line 3821 -- #if defined(BUG_7770_FIXED)
|| defined(XP_PC)
/mailnews/news/src/nsNNTPProtocol.cpp, line 3825 -- #endif /* BUG_7770_FIXED */

Comment 26

19 years ago
I tried to send mail, but the server's down *again*.  So Bugzilla discussion it is.
  I've done as suggested above, and put breakpoints at the top of the two functions in nsMsgPrompts.cpp
where #if BUG 7770 code appears.  And then I composed and sent a message.  Not only did I see
no alert dialog, I never hit either breakpoint.  Fingers poised over the "works for me" button once again.....
  (PS -- this bug was moved out to M8 (not by me; presumably by my manager) after noticing that though
it was marked critical, since the code had already been hacked to work around the problem, it didn't seem
like an M7 showstopper.)
it's not an m7 stopper, since the code is turned off.
we can live with out those few alert dialogs for m7.

if your mailserver is down, configure 5.0 for news, and try cancelling a

that will give you alerts and confirm dialogs to test.

My impression from davidm was that he (and you) were aware of these problems on
linux.  Are there no other alert / confirm dialog bugs on linux?
to cancel in 5.0, select article, hit delete.


19 years ago
Resolution: WORKSFORME → ---

Comment 29

19 years ago
Clearing WorksForMe resolution since this bug is now set to Reopened

Comment 30

19 years ago
Just adding a little status, since I haven't said anything about this for a while.
This is a general problem, happens on all platforms under some conditions, and the
conditions change from day to day and appear to be timing dependent.  Everyone
knows about the problem; no one understands how to fix it.  Haven't given up yet...


19 years ago
Whiteboard: kind of fixed
Target Milestone: M8 → M9

Comment 31

19 years ago
Extra Repaint()s added recently have cleared up a lot of non-drawing problems.  This particular problem
seems gone now, but others are moving in to fill the vacuum.  The dialog begins drawing, but the app then
crashes horribly.  I want to say the drawing problem itself is fixed, though you still can't use the affected
dialogs.  So there's a new problem here, and because of the late date vs M8, I'm going to move this off to
M9.  I'll have a little more time then to figure out the new problem.


19 years ago
Last Resolved: 19 years ago19 years ago
Resolution: --- → REMIND

Comment 32

19 years ago
Actually, this is fixed.  I'm reluctant to call it that, though, because there are other gtk dialogs
which don't work, and I don't yet understand the difference.  However, I'm knuckling under
to the pressure to call bugs something besides "open," so I'm dropping this one into the "remind"
black pit.

In the meantime, though, I don't know how safe this is, but if you turn on the BUG_7770_FIXED
flag in today's build, you do actually get dialogs on all platforms.
Whiteboard: kind of fixed
re-opening bug.

I still get an empty window, linux and windows.

nsNNTPProtocol::Cancel() calls Alert().

I think Alert() is being called from the necko thread.

Here's the stack right before Alert() is called.

nsNNTPProtocol::Cancel() line 3909
nsNNTPProtocol::ProcessProtocolState(nsIURI * 0x0ade4114, nsIInputStream *
0x0ade2970, unsigned int 572, unsigned int 8) line 4798 + 8 bytes
nsMsgProtocol::OnDataAvailable(nsMsgProtocol * const 0x0ade2c70, nsIChannel *
0x0ade28c0, nsISupports * 0x0ade4114, nsIInputStream * 0x0ade2970, unsigned int
572, unsigned int 8) line 152 + 32 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x0ade4320)
line 350
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0ade4324) line 149 + 12 bytes
PL_HandleEvent(PLEvent * 0x0ade4324) line 509 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00acb460) line 470 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00bc03a8, unsigned int 49273, unsigned int 0,
long 11318368) line 932 + 9 bytes
USER32! 77e71250()

To reproduce,

do this:

cd mozilla/mailnews/news
nmake -f clobber
add this line to mozilla/mailnews/news/src/nntpCore.h

#define BUG_7770_FIXED 1

rebuild news
nmake -f

select a news message and hit cancel.

note, the new stack trace is different than before necko landed.

this is becoming a blocker for me.


19 years ago
Resolution: REMIND → ---
Whiteboard: blocker for sspitzer

Comment 34

19 years ago
clearing resolution. updating status whiteboard.


19 years ago
Target Milestone: M9 → M10
OS: Linux → All
Summary: [PP] alert problem on Linux → alert windows are empty.
changing summary and OS.  this is no longer a [PP] bug.


19 years ago
Severity: critical → blocker
Priority: P3 → P1

Comment 36

19 years ago
Marking as blocker per putterman, raising priority to p1


19 years ago
Blocks: 11091

Comment 37

19 years ago
Have you tried this since the new dialog code went in?
things are working on linux!

I'm seeing all three dialogs I hoping to see:

	do you want to cancel
	message cancelled
	this isn't your message, you can't cancel it.

Tomorrow, I'm going to test on mac and windows, and if it looks good, I'll mark
this fixed.


19 years ago
Whiteboard: blocker for sspitzer → difficult to reproduce. may be fixed.
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
sorry for the delay.  its working linux, windows and mac.

marking fixed.


19 years ago

Comment 40

19 years ago
I'm going to mark this verified.
I'm not seeing the same compose situation as I originally saw.
I am indeed seeing alert dialogs filled in, such as the Cancel dialog(s).
Verified using 1999092308m11 on nt4.0 and linux 6.0.
Having general trouble with my mac, but will open a new [PP] bug if I find any
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.