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.
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
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?
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.
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.
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
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
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.