Unable to receive/view large sized msgs. I'm not sure where the cutoff is for the size, but I tested it on a 19 KB sized msg. Try to copy'n'paste the text in http://www.mozilla.org/cvs.html in the compose window and send mail. ( it takes 30 seconds to paste in compose window editor) It behaves differently for POP and IMAP. POP: Able to send the msg. When I do 'Get Msg' the status bar reads "Receiving Message 1 of 1" and never responded back. IMAP: Able to send the msg and also Get msg. The msg shows up in thread pane. But when I click on the msg to view, the status bar reads "Downloading message" and never responded back. In both the cases Messenger *doesn't* freeze. Build and Platform: 2000-01-14-09-M13, Win NT 4.0. Additional info: I'm able to read a msg that has 100 kb *attachment* in it on an IMAP account, NOT on POP account.

Suresh, I noticed you are using a 1/14/00 build. Right now the tree is closed because these builds supposedly aren't useable. i.e. messages aren't getting download, you can display imap messages.... anything in mailnews that involves running imap or pop urls is apparently broken. I suspect these problems may just be related to that. Can we wait until these url problems are fixed and the builds get respun today and then retest on those? Or you could try this on a 1/13 build instead....

My mistake, All these are tested on 2000-01-13-15-M13 build. thanks for pointing it Scott. I have noticed the POP problem in some earlier builds also.

This sounds like an M13 bug to me. Scott, can you look into it?

Okay, here's what's going on: The document Suresh is copy/pasting from is filled with relative links. When you paste the message into the editor shell in the compose window and send the message, the editor instance tries to resolve these relative links against the about:blank url used to load the editor instance. Which of course fails and generates many assertions in debug builds. then when we later fetch and display the message by running an imap url, the html parser tries to resolve these relative links against the imap url used to run the message which of course also fails. Again many asserts are generated. But when all was said and done, the document did load on imap for me and the throbber didn't continue to spin using a 1/17 build. Here's what I'm going to do: 1) I don't believe this is an M13 bug 'cause the msg still loaded for me (suresh can you try on tuesday's builds again) although objects referred to by relative urls of course failed to load in the document. So there isn't anything wrong with receiving / viewing large messages. The problem was with the fact that the test case used came from the clipboard and used relative links. 2) Let's re-assign this bug to someone who knows about copy and paste implementation. They are the only ones that have the knowledge to correctly resolve relative urls when pasting into the editor window. Because they know the base url of the document. 3) When I pasted Suresh's example into the compose window it only took a couple seconds (2?) to show the pasted text. Suresh was seeing paste times of 30seconds! I wonder if this is because his machine has like 64MB of RAM and we were doing a lot of swapping? Moving to M14. Re-assiging to clipboard or editor person. Changing the subject to represent the real problem. I think either pinkerton or mcafee implemented the clipboard. I can't remember which one. I'll guess pinkerton and cc mcafee. =)

my job is the clipboard backend, not what the clients do or don't do with the data. As long as the data is correct from A to B, my job is done. Reassigning to akkana.

I'm not sure I understand this bug. Is this a request that on html Paste, the editor should detect relative URLs and rewrite them to be absolute with reference to the document from which they were copied? Which would also carry with it the request that copying somehow include information as to the original URL of the document being copied (which is not necessarily the case now)? If so, I think this feature request is going to get pushed way off. If I've misunderstood and it's actually simpler than that, please explain what is being requested here. Cc'ing Beth since this sounds like a new editor feature.

Charley says we used to do this in 4.x, probably at the time the Copy is done -- there was a call NET_MakeAbsoluteURL which took the document's address and the relative link and tried to reconcile them. Hopefully necko provides a similar method, but we'll have to find some way to pass the document's location along to the copy code (another output flag and argument, sigh?) since it's not available now. Not clear where this code should live -- output? clipboard? document? Beth says to mark this M17.

I'm very leary about pushing this out so far. Mostly because it has impact on requirements you may need from necko. What if M17 rolls around and you go to implement this and need a lot of work from necko which they may not have time for. I think it's pretty important that copy and paste work with web pages that contain relative links. It's very common and I don't think we should fail in these cases. Just my two cents.....

We need to get through critical beta tasks first. If we can resolve the more critical issues, then we can bring this one in closer. Granted, we need to assess how we can extract the necessary data from necko, but the implementation can wait. Akkana, can you ping Gagan or Warren and see what they say about grabbing the absolute path?

I've sent mail to gagan, warren and rhp asking. libmime has a method to do this, which suggests that necko may not. Perhaps we should consider moving the libmime method out to necko so it will be accessible to everyone?

I think when you copy the text of the page as html, you need to make sure all the relative links are converted to absolute ones, because you'll loose the notion of the document base URL in the copied text. Basically, you need to get the document nsIURI, and call NS_MakeAbsoluteURI (in nsNetUtil.h) using it for each link on the page before creating the html for the copy.

moving to m15

I've checked in code to convert relative links to absolute when they go through the clipboard. Frankly, though, I'm not convinced that this is the right thing to do: for instance, when pasting within a document, or between documents being edited simultaneously in the same directory. Filed bug 32768 on that issue. Closing this one.

We should mark this one as a dup of bug 32768.

*** This bug has been marked as a duplicate of 32768 ***

mark it verified/dup.