Closed
Bug 23980
Opened 25 years ago
Closed 23 years ago
FEATURE: Cliboard doesn't work with text containing relative links.
Categories
(MailNews Core :: Backend, defect, P3)
Tracking
(Not tracked)
M15
People
(Reporter: skasinathan, Assigned: akkzilla)
Details
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.
Comment 1•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: phil → mscott
Target Milestone: M13
Comment 3•25 years ago
|
||
This sounds like an M13 bug to me. Scott, can you look into it?
Updated•25 years ago
|
Assignee: mscott → pinkerton
Summary: Unable to receive/view large sized msgs. → Cliboard doesn't work with text containing relative links.
Target Milestone: M13 → M14
Comment 4•25 years ago
|
||
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. =)
Updated•25 years ago
|
Assignee: pinkerton → akkana
Comment 5•25 years ago
|
||
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.
Assignee | ||
Comment 6•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Summary: Cliboard doesn't work with text containing relative links. → FEATURE: Cliboard doesn't work with text containing relative links.
Target Milestone: M14 → M17
Assignee | ||
Comment 7•25 years ago
|
||
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.
Comment 8•25 years ago
|
||
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.....
Comment 9•25 years ago
|
||
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?
Assignee | ||
Comment 10•25 years ago
|
||
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?
Comment 11•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M17 → M15
Comment 12•25 years ago
|
||
moving to m15
Assignee | ||
Comment 13•25 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 14•23 years ago
|
||
We should mark this one as a dup of bug 32768.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 15•23 years ago
|
||
*** This bug has been marked as a duplicate of 32768 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•