Closed Bug 11471 Opened 25 years ago Closed 21 years ago

Error message when displaying message

Categories

(MailNews Core :: Backend, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
Future

People

(Reporter: scottputterman, Assigned: jud)

Details

I'm not sure whether this is for rhp or mscott.  And, this seems to be pretty
harmless, but whenever I click on a message I get the following message in my
console window:

Error: Can't load: file:///c|/temp/tempMessage.eml (80004005)

The message is still displayed so I'm not sure why it's complaining.
I bet it is neither of us....the warning may be coming from layout or necko. The
path looks properly qualified. I haven't seen this yet but I haven't built since
Friday. My build should be done in a little bit.
QA Contact: lchiang → pmock
Target Milestone: M10
I'm moving this to M10 since nothing bad seems to be happening.
These messages are coming out of the following location:

Y:\mozilla\webshell\src\nsDocLoader.cpp(2122):
printf("Error: Can't load: %s (%x)\n", url, aStatus);

Y:\mozilla\webshell\src\nsWebShell.cpp(2031):
printf("Error: Can't load: %s (%x)\n", urlStr, rv);

I would really rather have someone on that side of the fence look at this.

Scott, Can you reassign for me.

- rhp
Assignee: rhp → warren
reassigning to warren.  Warren, do you have any idea why we'd get this message
even though we're apparently able to load the file with no problem?
Assignee: warren → rpotts
Rick, can you throw this on your docloader pile...
I have a good guess. It's probably because of the problem I've been complaning
about in the newsgroup for a while without any answer =). NS_BINDING_ABORTED is
listed as an error code right now in necko but I don't think it is. When
displaying a message, we cancel the rest of the file url operation after we've
read in the appropriate byte range for a message. Canceling the operation causes
a value of NS_BINDING_ABORTED to be passed out to any OnStopRequest url listener
calls.

People are doing things like:
if (NS_FAILED(rv)) printf "we failed to load the url"....

but NS_BINDING_ABORTED really isn't an error code. I've had to special case all
OnStopRequest calls in mailnews to handle this condition. My guess is that
someone in the docloader is doing something similar.
Target Milestone: M10 → M12
m12
Moving milestones...
This sounds very similar to Jud's ftp case where he wants to read part of the
stream and then close it. This shouldn't produce an error.
Target Milestone: M13 → M15
Moving out to M15 - when I get back...
Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.
Target Milestone: M15 → M16
M16 has been out for a while now, these bugs target milestones need to be 
updated.
Is this still a problem with the latest nightlies?
Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.
Clearing very old milestone (M16) in hope of reevaluation.
Target Milestone: M16 → ---
Yes, this is indeed still a problem in even 0.8. I don't know if it's related to
anything else discussed, but I still get the same error. I load a news thread,
abandon it for a new window for awhile, and a modal error pops up in the news
window - "unknown error 80004005".
sounds like a necko loading problem and/or inconsistencies in return codes.
Assignee: rpotts → gagan
jud: did you read this bug? per mscott's comments this is docshell -- back to 
you to reassign.
Assignee: gagan → valeski
futuring.
Target Milestone: --- → Future
Does anybody still see this?
This was last reported about two years ago and I cannot reproduce it. I also see
(with a filesystem monitor) that mozilla does not try to access any temp mail
file when I click on a message (with pop).
Was this a problem with pop or imap?
Not seen anymore.
-> WFM
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.