13381 - message finish loading, but the barber pole and the animation keeps spinning

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

select a pop message, it will load it, but the barber pole and the animation
keeps spinning.

linux.

(I believe others are seeing it on windows.  and with imap and nntp messages)

Comment 1

[Ninoschka Baca]

Adding nbaca to Cc: list.

Comment 2

[Scott MacGregor]

bienvenu mentioned this to me on Saturday and tried to track it down. Looks like
the webshell wasn't telling us that the document was done being loaded
anymore...

I'm still trying to figure that out.

Comment 3

[Scott MacGregor]

Yeah...I finally figure this one out tonight....

Here's a short summary of the problem that I posted in the netlib newsgroup:
From mailnews, I was running a file url in  webshell A. This file
actually caused an iframe to get loaded inside of the webshell (which caused
another webshell, B to be created & embedded in the first webshell). Webshell B
ran another file url that was referenced in the file loaded into A.

Something happened last Friday. After Friday, webshell A's
OnEndDocumentLoad stopped forwarding the OnEndDocumentLoad to it's doc loader
observer. I tracked it down to the following line
in nsWebShell::OnEndDocumentLoad:
if (loader == mDocLoader)
{
         // do lots of interesting things like forwarding the
         // OnEndDocumentLoad call the doc loader's observer
}

When webshell A's OnEndDocumentLoad finally gets called, in my scenario,
the loader is not equal to mDocLoader. Thus, the call never gets forwarded.
I believe "loader" was the loader used to load the second file into
webshell B. It's getting passed from webshell B to its parent, webshell A.

If I remove this equality test, things work much better for me for my
url scenario. I'm properly notified of OnEndDocumentLoad.

Before I check in this fix, I'm trying to figure out why this ever worked before
(i.e. did something really just recently break? I'm not buying into that theory
after seeing the problem). And I need to find out from other groups if removing
that test is the right thing to do.

Comment 4

[David :Bienvenu]

well, this is a long shot, but could it be Scott P's changes to make re-sizing
the messenger window work? He re-arranged the way we use frames somewhat, though
I'm not sure exactly when he checked it in.

Comment 5

[Scott MacGregor]

I figured this problem out yesterday afternoon. It is really hairy and won't be
a problem when I land the new message display changes that don't involve writing
to a temp file.

I'm not going to fix this and will instead remove the problem when I land my
changes for news, pop and imap. (Hopefully this weekend...I just got imap
working today!!!)

Comment 6

[Scott MacGregor]

I actually just landed the changes for message display that I've been working on
for the past week. That should fix this problem by removing it entirely from
the picture =).

Marking as fixed.

Comment 7

[laurel]

OK using 1999-11-09-11m11 commercial builds on linux 6.0 and nt 4.0
OK using 1999-11-08-08m11 commerical build on mac OS 8.5.1