Closed Bug 190106 Opened 22 years ago Closed 22 years ago

IMAP connections hanging

Categories

(MailNews Core :: Networking: IMAP, defect, P1)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.3final

People

(Reporter: blizzard, Assigned: darin.moz)

References

Details

(Keywords: regression, Whiteboard: fixed1.3)

Attachments

(8 files, 4 obsolete files)

IMAP and nsSocketTransport log when connection hung
3.17 KB, text/plain
Details
Part of the log after the stop button was pressed
8.85 KB, text/plain
Details
stacks while it stalls
6.90 KB, text/plain
Details
tasty stacks for breakfast
14.11 KB, text/plain
Details
Log with StreamPump when it stalls
89.93 KB, text/plain
Details
Log with StreamPump when I pressed Stop after the stall
99.70 KB, text/plain
Details
Logfile with comments, search for xxx
92.77 KB, text/plain
Details
v1 patch
19.83 KB, patch
sspitzer
: review+
Bienvenu
: superreview+
asa
: approval1.3+
Details | Diff | Splinter Review 
Some time in the last day or so I've picked up a problem where connecting to
mailboxes never completes.  It usually happens after I've already opened a
mailbox  and then I don't look at it for a while.  When I re-click on the inbox
for that account it never finishes opening the folder.  I guess the connection
is timing out?

Also, if I try to close the mail window while in this state, Mozilla stops
redrawing windows and the mail window never finishes closing.
I doubt this is due to any imap changes - it's more likely some necko or nspr
changes since IMAP hasn't really changed.
I've seen bugs intermittently on this that kind of sound like
what Chris is describing (I could still be way off base here)
I think some similar (but didnt mention ssl) bugs are bug 189323,bug 178289,
bug 168520.

I haven't noticed it myself using trunk builds but will keep any eye.

-> me (most likely fallout from bug 176919)
Assignee: bienvenu → darin
Severity: normal → major
Priority: -- → P1
Target Milestone: --- → mozilla1.3beta
It's pretty easy for me to reproduce this if I walk away from my computer for
half an hour and then try to read mail again later.  I don't use biff.  Is the
disconnect not being registered?
yes, the imap server will drop the connection after 29 minutes of inactivity,
and that very likely could be what triggers the problem.
see also bug 189718 which could be related to this one
I'm not seeing 100% CPU usage here, though.  Just so that's clear.
Something simmilar happens to me (Linux 2003012222 nightly on Courier IMAP server)

I use local IMAP server -> very fast connection, no SSL

When I quickly click on various folders sometimes one connection 'hangs' -> the
throbber keeps spinning and the folders' contents won't appear. Clicking on stop
button and then again on the folder usually helps. I haven't seen it in older
builds.

Yep, that's exactly the behaviour I'm seeing.  So it's not SSL-related.

I'm also watching the log generated with IMAP:5 at the same time I'm reading
mail.  When a message fails to load (sometimes it's a message, and not just
loading a folder) the sequence looks like this:

1. I hit 'n' to go to the next unread message.
2. There's a small amount of traffic, looks like it's requesting the message.
3. Time goes by.  The message is not returned.
4. I get impatient and click on the next unread message after the one that was
selected.
5. There is an explosion of traffic and I can read the message I just clicked on.
6. I can now click on the previous message that I couldn't load before.

I'm not sure if that explosion of traffic includes both messages or not.  It's
hard to catch.  I'm going to try to get an actual snippit from the log where
this happens.
Summary: problems with SSL connections hanging → IMAP connections hanging
*** Bug 190329 has been marked as a duplicate of this bug. ***
this probably isn't related to bug 189718, since nsImapProtocol does not share
its network code with nsNNTPProtocol (nsNNTPProtocol inherits from nsMsgProtocol
like many of the other mailnews protocols, but nsImapProtocol does not).

i hit this bug myself, and when the IMAP connections got hung, i also could not
browse to any websites.  i think this must be a bug in the socket transport
service.  perhaps it is a duplicate of bug 189843.
Status: NEW → ASSIGNED
I haven't seen any problems with loading messages, as I was.  I am however still
seeing occasional problems where I can't open a folder which may or may not be
related.
I'm requesting a blocking 1.3b because it hits me very often and it is a recent
regression.
Flags: blocking1.3b?
Keywords: regression
Here are some excerpts from the NSPR LOG of IMAP module:

This time even the first connection (immediately after opening a Mailnews) hang.
5126[8d159c0]: ReadNextLine [stream=8d15cd0 nb=112 needmore=0]
5126[8d159c0]: localhost:NA:CreateNewLineFromSocket: * OK Courier-IMAP ready.
Copyright 1998-2002 Double Precision, Inc.  See COPYING for distribution
information.
5126[8d159c0]: localhost:NA:SendData: 1 capability
5126[8d159c0]: ReadNextLine [stream=8d15cd0 nb=0 needmore=1]
----> Then it hangs so I pressed the Stop button
5126[8d159c0]: localhost:NA:CreateNewLineFromSocket: (null)
----> This appeared in the log after that
----> So I tried to get the INBOX again and I succeeded
6150[8d7c6e8]: ReadNextLine [stream=8cdf058 nb=112 needmore=0]
6150[8d7c6e8]: localhost:NA:CreateNewLineFromSocket: * OK Courier-IMAP ready.
Copyright 1998-2002 Double Precision, Inc.  See COPYING for distribution
information.
6150[8d7c6e8]: localhost:NA:SendData: 1 capability
6150[8d7c6e8]: ReadNextLine [stream=8cdf058 nb=0 needmore=1]
6150[8d7c6e8]: ReadNextLine [stream=8cdf058 nb=108 needmore=0]
6150[8d7c6e8]: localhost:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1
CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE STARTTLS
.....

It happened to me again when I was switching between the folders. And it hang
again just after receiving the server Hello.

Hope this helps

Is this still happening after the other socket fixes that went in a couple days
ago? I haven't seen it anymore.
I fear I see this problem, too. I can't it reproduce often, but it's there.
Darin, is the NSPR log output helpful? Should we try to get more logs, possibly
from NSPR_LOG_MODULE=nsSocketTransport:5 ?

yes, a NSPR_LOG_MODULE=nsSocketTransport:5 log would be most helpful if you can
repro this using a recent trunk build.
what is the most recent build in which folks have seen this problem?  tom, kai?
It's still there (Linux nightly 2003012822). I've tried to make the
nsSocketTransport log but it doesn't dump anything to the log file. Do I need
some special build or what?

tom: thanks for the info.  you'd need to have a debug build of mozilla to
capture that log.
Not gonna hold beta for this but we should get it cleared up for 1.3final.
Flags: blocking1.3b? → blocking1.3b-
This is the part of the log before the connection hung and before I've pressed
stop button.
This is the part of the log after the stop button was pressed.
tom: can you better describe the things you did leading up to this hang?  i'm
suspecting that this hang is caused by stopping an IMAP load while necko is
suspended.  it seems as if perhaps necko is not being resumed/canceled correctly
such that remains in a suspended state.
The strange thing about the hang is that sometimes I can get it even immediately
after opening a mailnews (I have the IMAP account as default). So it hangs just
after the start. This happened in the comment 14. The attached logs are from
different hang which occured after 3 or 4 clicks on different folders in my
account. I didn't do anything else. So again:

1. started mozilla with -mail
2. dialog box asking for my password appeared -> entered the password for my account
3. clicked through the folders to get the hang
4. it hung.
5. pressed stop

Yeah, I don't ever use suspect/resume and I hang all the time.  It's almost
always on a connect, though - when you first open a folder or come back to a
folder that you haven't opened in a while.

Hitting Stop and then restarting opening the folder usually gets it going again,
though.
Attached patch v1 patch (obsolete) — — Splinter Review 
this patch might fix this bug.	it causes IMAP to poke necko after each line
read from the socket input stream.  i think the problem was that IMAP would
read from necko's buffer.  find the end of the last line, and never ask necko
for more data... because it is assuming that necko will send it more data when
more data becomes available.
can folks please give this patch a try for me?  it seems to fix the problem for
me (using kai's steps to repro).
I still hang with this patch in debug builds, although it appears to work in
optimized builds.
Attached patch v1.1 patch (obsolete) — — Splinter Review 
this is the same patch w/ the addition of a fix for a crash kaie hit.  i'm
still working on tracking down the hang.  kaie reported it on linux.  i've
tried to repro on win2k, but i've been unable to do so.  going to try linux
now...
Attachment #113458 - Attachment is obsolete: true
The patch didn't help here either. :-( (Debug build)

I haven't seen any hangs with the patch installed.  I've been using it all day
and I normally would see a few hangs.
Blizzard do you use optimized or debug build with the patch?

kai mentioned that he has a high latency connection to his mail server (~170ms
ping times)... the ping time to my mail server is ~30ms.  i wonder if this isn't
somehow a factor.  kaie is setting me up with a mail account on his machine in
germany so i'll be able to give it a whirl myself, but what about everyone else?
 high latency, low latency, doesn't matter?
I have almost 0 latency since it is an IMAP server on the same computer I use
Mozilla or (in case of the debug build) it is only one hop over 100MBit Ethernet.

I just pulled and built the latest trunk, my previous tree was about 2-3 days old.
There were no updates in netwerk or imap code.
I currently do not have Darin's patch from this bug in my tree.

However, I can not reproduce this bug at the moment, neither debug nor optimized
build. :-(

I will try again later when there is again traffic on the mail server.
Out of 100 attempts or so, I just saw it again. Once.

I can't reproduce it reliably. I have now produced a debug build from the latest
sources, with v1.1 patch applied.

Darin, if it hangs again, is there anything I could do by attaching with the
debugger and looking where it hangs?
Attached file stacks while it stalls — 
It happens when are not trying to reproduce it :-)

I attached to the hanging process with the debugger.
I'm attaching a text file that has stack traces from all active threads.

Both nsImapProtocol::CreateNewLineFromSocket
and nsImapProtocol::ImapThreadMainLoop are looping, 
no data, nothing resumes.
I use an optimized build.  My mail servers aren't local but the latency to them
isn't too high.
Hey, check that out, I just hung with my build this morning.  First time, and
the stack traces look about the same.  I'll attach them in a moment.
so, IMAP is basically waiting for something from the server:

  nsImapProtocol::CreateNewLineFromSocket

is waiting on necko to send it an OnDataAvailable event.  does anyone have
nsSocketTransport:5,nsStreamPump:5 logs to go with these stack traces?  anyone
happen to look at the output of "netstat -tcpd" to see if moz has any open
sockets to your imap server?

this has got to be more than just imap leaving necko suspended.
Yes, there is connection to the IMAP server from the stalled thread.
And it is closed after the STOP button is pressed.

And (only my guess) it seems that if the (previously working) connection is
reused  it never hangs. Only newly created connections sometimes hang.


*** Bug 192006 has been marked as a duplicate of this bug. ***
I can readily reproduce the problem in bug 192006 on Win2K systems and would be
very happy to test a patched and compiled version of mozilla and see if it
resolves the problem.
OK, asking for blocking 1.3 final.
Flags: blocking1.3?
I'm writing my own oracle database back ended mail server which implements imap
and pop.  This worked fine up until 1.3b (1.3a and previous worked fine).

Here is the log of an IMAP session (it hangs straight away):

1616[27b57a8]: ReadNextLine [stream=23cc500 nb=0 needmore=1]
1616[27b57a8]: full.its.deakin.edu.au:NA:CreateNewLineFromSocket: (null)
1040[24a8608]: ReadNextLine [stream=2563fa0 nb=0 needmore=1]

Is this the same bug you are referring to here or a seperate one?
Setting as a blocker to 1.3.
Flags: blocking1.3? → blocking1.3+
I also the problem described here with 1.3a and 1.3b builds (Linux i686):
Mozilla does not show mails from one folder, usually the Inbox. If a click into
another folder, everything is ok. If I click back to the Inbox, it seems to hang
again. If  I exit and restart, it works. 
The same happens to me using the nightly builds on Linux and IRIX.
IMAP server is Cyrus 2.0.9 on the same LAN.
Frank,

can you please clarify something:  you said you observed this bug using Mozilla
1.3 *alpha*.  Is that correct?  Others have said that this bug only occured
recently (NOTE: this bug was filed Jan 22, 2003).  thanks for clarifying!
As mentioned in bug 192006, I have done some testing of when I hit this problem
and BuildID 2003011608 doesn't exhibit it, whereas BuildID 2003011808 does.
BuildID 2003011708 doesn't have the IMAP problem but does have a problem of the
mozilla process not dying off when it's closed which I presume is another bug.
This testing was all done on Win2K. Marking OS as all.
OS: Linux → All
Target Milestone: mozilla1.3beta → mozilla1.3final
I have an interesting bit of trivia.  I hit this bug this morning on an SSL
server that has a mismatched certificate (actually, it's running through an ssh
tunnel, but that's not entirely important.)

Anyway, connecting to this mailbox always causes the warning dialog to appear. 
In this case, that dialog never appeared until I hit stop and then re-checked
the mailbox for new mail.  It never got to the point where it would generate
that warning dialog.

This might help, no?
Answer to Comment #53 From Darin Fisher: (sorry for the delay)

Yes, it was  "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212"
I reproduced the problem with this old version a few minutes ago. I also checked
the latest "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030214",
but there is no difference.

To clarify it further, I might also write down how I can reproduce it:
- I open DSL connection to get connection to my imap server (via SSL) 
- Open Mozilla and open the Inbox, Mozilla loads the message headers, 
  e.g. there are 5 new messages
- I open new message #1, ok
- NOW: I close my DSL connection manually (or it is close automatically 
  after a certain time), but Mozilla is left in "Online" mode
- I try to open #2: Ooops, Mozilla window does not show the message, 
  but ok, I'm not connected
- So, I open the DSL connection again and try to open message #2 again. 
  but it does not work, Mozilla seen to be hanging
- I try to open unread message #3, it does not work
- I look at another mail folder: everything is fine!
- I come back to my Inbox: nothing has changed, I cannot open message #2 or #3
  or one of the other unread mails
- Additionally: I send some test mails to this IMAP-Server, but Mozilla does 
  not discover that new mails have arrived, still seem hanging!
- After I exit Mozilla and restart it works again.
I checked with tcpdump/ethereal what's going on when Mozilla hangs on an IMAP
connection. It was done using Mozilla build 2003021408 on Linux.

Mozilla is configured for two IMAP accounts on the same IMAP server (Cyrus
2.0.9). Mozilla and Cyrus are on two different Linux boxes but on the same LAN.
tcpdump -w was running on the IMAP server.

mozilla -mail was started and it logged in at 11:07:31 to the first account
using src port 33777/tcp. There was one new mail and I deleted it.

The second account was checked for new mail at 11:17:29. Mozilla used src port
33788/tcp. One new mail was read but not deleted.

At 11:27:29 I clicked on the folder INBOX.postmaster of the first IMAP account.
Mozilla opened another connection with src port 33811/tcp. Mozilla hung until I
closed it several minutes later.

Analysing tcpdump's trace with ethereal showed the TCP connection was well
established (SYN, SYN/ACK, ACK). Then Cyrus sent "* OK ente.berdmann.de Cyrus
IMAP4 v2.0.9 server ready". This TCP segment was acknowledged. No further
communication.

Conclusion: Mozilla tried to open another IMAP connection, got a login prompt
from Cyrus but did not react.
I spent the last 3 hours with tracing and debugging.

I can prove the IMAP server is sending the hello line (96 bytes), but the stream
pump does sometimes not call nsImapProtocol::OnDataAvailable.

I'll attach a NSPR logfile with IMAP:5,nsStreamPump:5,nsSocketTransport:5 with
some inline comments.
Logfile that shows that 96 bytes were received, but stream pump does not call
OnDataAvailable.
*** Bug 193856 has been marked as a duplicate of this bug. ***
*** Bug 193876 has been marked as a duplicate of this bug. ***
I see the exact same behaviour than Frank in comment #51 and #56
And, after reading comment #55, I'm 90% sure that my mail server
has a mismatching certificate.

*** Bug 193735 has been marked as a duplicate of this bug. ***
kaie sent me a modified IMAP log that indicates the problem:

1024[80d41f8]: 8634338:judge.netscape.com:NA:SetupWithUrl: clearing
IMAP_CONNECTION_IS_OPEN
1024[80d41f8]: creating nsSocketTransport @8a29d88
1024[80d41f8]: nsSocketTransport::Init [this=8a29d88 host=judge.netscape.com:143
proxy=:0]
1024[80d41f8]: nsSocketTransport::OpenInputStream [this=8a29d88 flags=0]
1024[80d41f8]: nsSocketInputStream::AsyncWait [this=8a29e00]
1024[80d41f8]: nsSocketTransportService::PostEvent [handler=8a29d94 type=3 u=0 v=0]
10246[8856f00]: ImapThreadMainLoop entering [this=8634338]
10246[8856f00]: 8634338:judge.netscape.com:NA:ProcessCurrentURL: entering
1026[8187738]: nsSocketTransport::OnSocketEvent [this=8a29d88 type=3 u=0 v=0]
1026[8187738]:   MSG_INPUT_PENDING
1026[8187738]:   calling PR_Poll [active=0 idle=0]
1024[80d41f8]: nsSocketTransportService::PostEvent [handler=8a29d94 type=0 u=0 v=0]

notice the PostEvent calls issued from thread 1024 (that's the UI thread in this
example).  notice that there is a PostEvent call for type=0.  that corresponds
to the PostEvent call issued inside nsSocketTransport::OpenInputStream before
the function returns.  IOW, when we switch to thread 10246, m_inputStream has
not yet been set.  Thus, when we execute ProcessCurrentURL, we find that
m_inputStream is null, and therefore we do not create a nsInputStreamPump.  the
result is that the nsImapProtocol will never be notified to read from the socket
input stream.

now that i understand the problem, i think i should be able to come up with a
patch...
Attached patch test patch (obsolete) — — Splinter Review 
this patch contains a fix, but it needs to be cleaned up a bunch before it is
ready to go into the tree.  this patch has some code (that won't be in the
final patch) that allows you to set TEST_BUG_190106=1 in your environment to
make this bug more easily reproducible.  the guts of the patch are changes to
ImapThreadMainLoop.
Attachment #113466 - Attachment is obsolete: true
I've applied and tested the patch. While I was able to easily reproduce the hang
without the patch, I'm not with the patch applied. Seems fixed to me! Thanks!

some notes / comments.

1)

we should make sure to cvsblame / ask around about the 
IMAP_FIRST_PASS_IN_THREAD flag, see what bugs it was trying to fix and see that 
we haven't regressed them.

2)  

I was able to reproduce this wedge by adding PR_Sleep() call before m_transport-
>OpenInputStream()

(I also tried adding a PR_Sleep() call to the start of SetupWithUrl() but it 
didn't cause a wedge.  
I'm not sure why yet.)

3)

I'm a little nervous about how your change affects queued urls.

The risky part of the change is the code you if 0'd out.

before, using the IMAP_FIRST_PASS_IN_THREAD flag, we'd call ProcessCurrentURL() 
if it was the first time in, if we had a
m_runningUrl and a m_transport.

[this is the bug though, since we might have the transport, but not the input 
stream]

+#if 0
   // if we are making our first pass through this loop and
   // we already have a url to process then jump right in and
   // process the current url. Don't try to wait for the monitor
@@ -1170,14 +1182,14 @@
     }
 
     if (DeathSignalReceived()) break;
+#endif


But from ProcessCurrentURL()

  // now try queued urls, now that we've released this connection.
  if (m_imapServerSink)
  {
    if (GetConnectionStatus() >= 0)
    {
      rv = m_imapServerSink->LoadNextQueuedUrl(&anotherUrlRun);
      SetFlag(IMAP_FIRST_PASS_IN_THREAD);
    }
    else // if we don't do this, they'll just sit and spin until
          // we run some other url on this server.
      rv = m_imapServerSink->AbortQueuedUrls();
  }

Will your patch do the right thing in the scenario where we are loading queued 
urls?

I think it will, because of this line of code in your patch:

m_nextUrlReadyToRun = ProcessCurrentURL();

If we have a queued url to run, ProcessCurrentURL() would return PR_TRUE and 
we'd skip the while loop you added

+      while (err == PR_SUCCESS && ImapThreadIsRunning() && !DeathSignalReceived
() && !m_nextUrlReadyToRun)
+        err = mon.Wait(sleepTime);

Does that make sense?  We'll have to test queued urls.

4)

We should test things like going online, offline and then back online, 
and starting up offline and going online, but I think we should be ok.

5)

looking at your patch, you've made IMAP_FIRST_PASS_IN_THREAD flag unnecessary.  

if the patch sticks, we should remove the calls to Test, Set and Clear that 
flag.


6)

while looking over the existing code, I found minor we should fix

from:

PRBool nsImapProtocol::ProcessCurrentURL()

        nsCOMPtr<nsIRequest> request = do_QueryInterface(m_mockChannel);
        if (!request) return NS_ERROR_FAILURE;
        rv = m_channelListener->OnStopRequest(request, m_channelContext, NS_OK);

we shouldn't be returning NS_ERROR_FAILURE here (since the return val is a bool)

I think we should assert, and skip the call to OnStopRequest();

7)

please keep the logging changes as part of the final patch.
thanks for the comments seth.  i agree with you on all points.

>I think it will, because of this line of code in your patch:
>
>m_nextUrlReadyToRun = ProcessCurrentURL();

right, that was my intention.  but, like you said, this definitely needs some
serious testing.
BTW, is it possible that this bug has been lurking in the code for a longer time
in a shows-extremely-rarely fashion? I remember seeing some hanging connections
once in a while in the past too. If this is the same problem, I'm very happy to
see it fixed.
QA Contact: gchan → esther
> BTW, is it possible that this bug has been lurking in the code for a longer 
> time in a shows-extremely-rarely fashion? 

yes, according to darin.
note to darin, mon.Wait() returns a nsresult.

So I think we want this:

    nsresult rv = NS_OK;
    {
      nsAutoMonitor mon(m_urlReadyToRunMonitor);
      while (NS_SUCCEEDED(rv) && ImapThreadIsRunning() && !DeathSignalReceived
() && !m_nextUrlReadyToRun)
        rv = mon.Wait(sleepTime);
    }
    if (NS_FAILED(rv) && PR_PENDING_INTERRUPT_ERROR == PR_GetError()) 
    {
      printf("error waiting for monitor\n");
      break;
    }
I've been running with the attached patch.  so far, so good.  queued urls seem
to be working (I've testing that by moving several imap messages at once.)

I haven't tried offline (or offline playback yet)
I think there may still be a race between the UI thread and the IMAP thread to
set m_nextUrlReadyToRun.  I think we need to clear m_nextUrlReadyToRun before
leaving the monitor, so we can properly detect if the UI thread has set it
again.  I'll cut a revised patch.
Actually I hope this might fix another problem I have been seeing for a long
time in previous versions. I usually run into the stalling situation, too, when
I look at the files in my INBOX, and double click a message that is not
currently selected. The double click has two effects. It will select the message
and in addition open the message in a new separate message window. What I
usually saw was, the message gets displayed in the main mail window, and the new
message window opens, too, but loading the message in the new window stalls.
Kai, that problem should have been fixed for a while now (a couple months, I
believe).
Attached patch v1 patch — — Splinter Review 
ok, this patch adds a bit more safety to the assignment of m_nextUrlReadyToRun.
 i've also cleaned up a few other things.  consider this a candidate final
patch ;-)
Attachment #114949 - Attachment is obsolete: true
Attachment #115013 - Attachment is obsolete: true
*** Bug 194282 has been marked as a duplicate of this bug. ***
*** Bug 194239 has been marked as a duplicate of this bug. ***
I was trying to imagine how there would be a race between the UI thread and the 
IMAP thread for m_nextUrlReadyToRun.

Here's darin's explanation:

imagine ProcessCurrentURL() wanting to return PR_FALSE
and imagine LoadUrl() has just set m_nextUrlReadyToRun = PR_TRUE

basic rule: only assign variable inside lock
but in this case, assigning to TRUE is ok, since the other thread (the UI 
thread) only ever assigns TRUE
assigning to FALSE outside lock is bad

bad:

     if (m_nextUrlReadyToRun && m_runningUrl)
     {
        m_nextUrlReadyToRun = ProcessCurrentURL();
     }

good:

     if (readyToRun && m_runningUrl)
     {
       if (ProcessCurrentURL())
         m_nextUrlReadyToRun = PR_TRUE;
     }

if we did it the bad way, a well timed called to LoadUrl() 
(which sets m_nextUrlReadyToRun to PR_TRUE) would get ignored
if ProcessCurrentURL() returns PR_FALSE
Attachment #115048 - Flags: review?(sspitzer)
Comment on attachment 115048 [details] [diff] [review]
v1 patch

r/sr=sspitzer
Attachment #115048 - Flags: review?(sspitzer) → review+
Comment on attachment 115048 [details] [diff] [review]
v1 patch

sr=bienvenu
Attachment #115048 - Flags: superreview+
Comment on attachment 115048 [details] [diff] [review]
v1 patch

requesting drivers approval for 1.3 final.  this bug has actually been with us
for a long time, but my recent changes to necko caused this to show up much
more frequently.
Attachment #115048 - Flags: approval1.3?
Comment on attachment 115048 [details] [diff] [review]
v1 patch

a=asa (on behalf of drivers) for checkin to 1.3
Attachment #115048 - Flags: approval1.3? → approval1.3+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
verified with recent trunk builds
Status: RESOLVED → VERIFIED
blizzard / kai, can you verify as well?
This fixed the problems I was seeing.  Thanks heaps (I thought it was my mail
server code for so long)... still doesn't explain for me why uw-imapd never
paused for me.. anyway.. works great again now.
I haven't seen any hangs since using this, but I haven't been using it too much,
either.
*** Bug 193995 has been marked as a duplicate of this bug. ***
Works on AIX now.
I cannot reproduce the problems described in Comment #53 and Comment #56 with

   Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030225

Thanks!
The bug is fixed for me, too.
Verified.
Whiteboard: landed1.3
Whiteboard: landed1.3 → fixed1.3
*** Bug 191929 has been marked as a duplicate of this bug. ***
Depends on: 191929
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: