Build 2001011904, Windows 2000. Summary: We're getting too much info on a copy of 'definitely'. Steps to Reproduce: Visit http://www.dictionary.com/cgi-bin/dict.pl?term=definitely Scroll down to about mid-page Select the string "defi·nite·ly adv. " Expected Results: Next time you paste, the string should be "defi·nite·ly adv. " Actual Results: and you get: <http://cache.dictionary.com/dictionary/graphics/AHD/prime.gif> i·nite·ly adv.

anthonyd, is this yours?

I see this on Macintosh too. I'm not 100% convinced that this is a bug. The html for that page is full of images. On another page, if you copied an image, you'd expect to get the url for that image in the text (assuming you are pasting into something that handles only text). Perhaps this should be resolved as WONTFIX or INVALID? Probably we should discuss this in a newsgroup or on IRC or ???.

No discussion needed. They use images as spacers to seperate consonants. Marking IVALID. Sorry guys ;-(.

and..verified.

Wait...what? Even if we know that there's spacer images separating those, the average user doesn't. We need to copy what the user sees visibly selected, as IE and 4.x do. Otherwise it's going to take the user much longer just to copy that word than it should.

`Copy' should never copy an image URL; that's what `Copy Image Location' is for. Into the image and rich-text parts of the clipboard, `Copy' should copy the image. Into the plain-text part of the clipboard (which is what this bug is about), `Copy' should copy the ALT content of the IMG if there is one -- or, for an OBJECT, any text content which is inside the OBJECT. If such content does not exist, no text should be copied at all.

the issue is what to do with the html data flavor. There you want to make a url of some sort.

The user definitely isn't expecting an URL of some sort. Even pasting nothing would be better than that. You could copy <img src="remote-url-adjusted-to-be-absolute">. The only problem with that is that HTML-format mail users could create inadvertent Web bugs ... But then, given that HTML-format mail users can attach pictures to their messages just like the rest of us can, I don't think they should be able to insert remotely-stored pictures into the message itself at all.

marking nsbeta1-, setting to moz0.9.1 and reassign to anthonyd

I remember discussions with BenB about what plaintext copy should do for images, and I remember him convincing me that he was right, but now I don't remember what he convinced me of. :-) Cc'ing him in case he has a comment on this. But personally I have a hard time being concerned about special-casing copy just so that on a page that uses images to separate consonants it pretends that the images aren't there. Good grief. I do remember that we should be copying alt tags, not image urls, when we do copy images, so if the web authors put in alt tags saying "-" or something like that (which they'd need to do to make their page work on text browsers anyway) then we should do the right thing, unless there was a regression when we went from nsHTMLToTXTSinkStream to nsPlaintextSerializer.

I don't think we need to special case anything: image urls should never be copied. Unlike IE (which doesn't copy image urls), we don't even change the image appearance when they're selected, so it's definitely a surprise when the urls get copied. Copy Image Location is how you copy the location of an image; what we do now is a major usability problem, not to mention confusing (e.g. even though I think my mother grasps the concept of an Internet site having an address, I don't think she understands that images have them also).

akk, I think you refer to me convincing you that <img alt="" ...> should copy nothing at all. I based my comment on specs or guides from w3c. The page author should have specified either alt="" or alt="-". Nevertheless, the code to insert the URL was intended for the "rich" flavor of the converter, for the case the user inserts an image into an HTML mail and sends it as plaintext or multipart/mixed. If we don't insert the URL, all hints that there ever was in image wold be removed, in most cases. Not acceptable. So, an OK fix would be not to output the URL, if we in the less-styled mode of the converter, which is made primarily for Copy.

:-) someone needs to decide what the solution to this bug is, and that solution should make MOST people happy and NOT be something wierd, edge case, or just plain insane. I know this is assigned to me, but I can't even pretend to know what the happy happy solution here is. anthonyd

Ok, how about this, for pasting the HTML flavor. (Pasting plain text and image flavors is covered by my 2001-01-22 comment.) * If the user pastes a selection into the HTML editor which contains nothing except one (1) image (and possibly whitespace), then an Insert Image dialog pops up, pre-filled for inserting the image as it was in the copied content. This isn't wacky -- it's just what the Sounds control panel does when you paste a sound into it. * In any other case (i.e. pasting content which contains non-whitespace text and/or contains multiple images), the alt text is pasted instead of the image.

> the alt text is pasted instead of the image. We are talking about the case when no alt is available. If it is, we will use that and no bother about the URL.

If i have a web directory of images (say 100) from my family photo album that kodak put online. Are you all saying that i should copy each image location one by one; paste; click ok; repeat 100? If I select the entire album in navigator; copy it; paste into composer I think it's more reasonable to copy the html and paste it as code which then looks the same as it did before. This is a real world possibility. Average users don't use view-source [and i have no idea how to insert html into messageComposer], but they do have photoalbums w/ many images.

Absolutely -- if I make a selection spanning an image (or several), and paste it *into html*, I expect to see pasted exactly what I copied, images and all (as Timeless says). Though Matthew's idea of popping up an image dialog if we're pasting exactly one image and no more is interesting and might be worth pursuing (that would be a separate RFE, no?) This bug, as I understand it, concerns what happens when we copy an image (or content spanning one or more images) and paste into plaintext.

taking this bug; I have a similar one

moving to mozilla1.0

the argument of copying into some application that understands html doesn't make any sense, because then it must copy all html, not only image urls. and i think noone wants that for plaintext copy-paste. maybe it's too late for 1.0, but one possibility would be to include this into preferences, or have a context menu "copy html", but default should always be without the urls.

fix component and reassign

*** Bug 97910 has been marked as a duplicate of this bug. ***

It look a bit stupid to copy HTML using copy/paste, the reason is WYSIWYG :) If people really need url and such stuff, why dont they use HTML Source (View/Source) or open the page in composer ? Just my 2 cents.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

*** Bug 88115 has been marked as a duplicate of this bug. ***

this simply removes 7 lines from nsPlainTextSerializer.cpp which made it copy the image url if there was no alt="something" no alt="" and no title="something". this also affects javascript window.getSelection() which is ok imho, because i think the bug is about what a user should get when he expects plaintext. and it's plaintext in both, plaintext clipboard and getSelection() ...

sorry for the mess, it's my first patch and was in the wrong format... so this should be the right format...

See my comment #12. You are removing it from all cases. This is a general HTML->TXT converter, not limited to copy&paste. It is used for sending plaintext mails, for example. If a user composes a mail in the HTML composer, inserts an image and sends it as HTML+plaintext (or plaintext only), the plaintext version will have no trace at all of the image. A user reading that version will have no hint that there ever was an image. But the plaintext version is supposed to be equivalent in information. Ergo, we lost data. We have a special mode in the converter for copy&paste ("simple" mode or something like that). If you (all) think that we should remove the URL for copy&paste, then remove it in that mode *only*.

Comment on attachment 60979 [details] [diff] [review] proposed patch (removes URL for all modes) better do something like: else if (NS_SUCCEEDED(GetAttributeValue(nsHTMLAtoms::src, desc)) && !desc.IsEmpty() && isCopyAndPaste)

did you ever compose an html mail with mozilla and sent it plaintext? it first pop's up a message that you _really_ should set an alt text. and if you don't, alt is set to "" and you're not seeing anything anyway. but i will file a bug on what plaintext is in general, and attach my patch there...

which bug?

*** Bug 114287 has been marked as a duplicate of this bug. ***

ok, so what about window.getSelection? should that return the image urls or not?

If you're asking me: I don't know and don't care. Probably what a copy&paste gives.

Why would you ever want the <http://www.example.com/image/spacer.gif> images to appear in <http://www.example.com/image/spacer.gif> the middle of your text? If alt="", then the equivalent text representation of the image _is nothing_. That's exactly what alt="" means. If you have a border around a paragraph in HTML mode, it doesn't appear in text mode, because it is purely decorative. That's exactly what alt="" means. The image is purely decorative. r=hixie for attachment 60979 [details] [diff] [review] (the second path in this bug).

Hixie, > If alt="", then the equivalent text representation of the image _is nothing_. > That's exactly what alt="" means. And that's exactly what we do. Again: We are talling about the case where no alt attribute is specified at all. This is completely different in meaning from alt="", just like "I know that Joe has no money" is different from "I don't know, how much money Joe has".

so can we say that this bug is dependend on bug 114531 somehow? and the patch would be ok, if there was a better way for the composer to deal with alt's. imho, if a user sends a mail plaintext he/she is aware that there will be no images... and either it is so important that he as the alt attribute set, or it is not important and the image url isn't important either.

Sorry for the ambiguity, I was replying to the following: > If a user composes a mail in the HTML composer, inserts an image and sends it > as HTML+plaintext (or plaintext only), the plaintext version will have no > trace at all of the image. ...and was assuming that our editor doesn't create invalid HTML. It was decided to not use the src attribute to create the alt text of images in layout. Why is the HTML->TXT convertor any different? (In fact, why isn't it using the same function? I bet the current HTML->TXT code fails to handle image inputs correctly too.)

The alt attribute is a required attribute, so when the alt attribute is absent I think it's fair game to interpret that as if the attribute were set to "". This also conforms to the intent of the spec: <http://www.w3.org/TR/html4/struct/objects.html#adef-alt>

to comment #38 that _is_ the current state. composer _does not_ create invalid code and _does insert_ an alt="" if no alt is specified. so my patch wouldn't change the behaviour for html->text conversion in mail composing anyway.

> It was decided to not use the src attribute to create the alt text of images in > layout. Why is the HTML->TXT convertor any different? The url in alt would be redundant and specifically against the spec <quote src="http://www.w3.org/TR/html4/struct/objects.html#adef-alt"> * Do not specify meaningless alternate text (e.g., "dummy text"). Not only will this frustrate users, it will slow down user agents that must convert text to speech or braille output. </quote> Not adding the URL as alt (but instead adding no alt at all) does no lose any info. OTOH, when we just drop the url, we do lose info - there will be no way anymore to get to the url. > when the alt attribute is absent I think it's fair game to interpret > that as if the attribute were set to "". This > also conforms to the intent of the spec: > <http://www.w3.org/TR/html4/struct/objects.html#adef-alt> Where do you read that intent? I read the spec and the W3C access guidelines when implementing these converter rules and obivously found no such intent. If you mean the paragraph I cited above: We are not a speech or braille browser, we convert to plaintext, and there it is not unusal to have embedded URLs like the way we output it. I am so reluctant to removing the URL, because it is potentially important to the content, and my goal was not to lose any such info while converting to plaintext, i.e. make plaintext a full alternative. I don't think that bug 46990 would change anyone's opinion of this matter?

> so can we say that this bug is dependend on bug 114531 somehow? (That the bug I filed about Composer's behaviour of inserting alt="".) rossi, good note that this won't change our mail behaviour. With bug 51798, this code is relevant to any webpage however. Does noone agree with me? I don't want to be pigheaded, but I get a bad feeling at the idea of removing alls hints to a image that might be relevant to the content. Better too much info than too less IMO.

>rossi, good note that this won't change our mail behaviour. With bug 51798, this >code is relevant to any webpage however. i don't know what you mean... bug 51798 is for composer exporting as text. and composer is same for web pages and mails. so web pages exported as text aren't touched by this patch either, because there the same mechanism adds alt="" to images without alt attribute defined. > Does noone agree with me? I don't want to be pigheaded, but I get a bad feeling > at the idea of removing alls hints to a image that might be relevant to the > content. Better too much info than too less IMO. i think it's ok to change the text in composer, which alerts you to add alt text, but i don't think we should add no alt tag, because that's not valid. you said yourself that we should not set the url as alt attribute, because that's bogus info. so what's the point in creating a pseudo-tag with the url in it, the only difference would be that it writes <http://url> instead of [ http://url ]

> i don't know what you mean... bug 51798 is for composer exporting as text. Sorry, I meant bug 42441. > you said yourself that we should not set the url as alt attribute, because > that's bogus info. so what's the point in creating a pseudo-tag with the url > in it, the only difference would be that it writes <http://url> instead of > [ http://url ] The difference is that one is a *generic* HTML document, and we don't know what will output it in which way. For example, an URL read in speech will probably sound bad, esp. during normal browsing; same with Braille. In our case, however, we do know the output medium and its customs.

> The difference is that one is a *generic* HTML document, and we don't know what > will output it in which way. For example, an URL read in speech will probably > sound bad, esp. during normal browsing; same with Braille. In our case, however, > we do know the output medium and its customs. i never really wanted to include the url in the alt tag. that's completely clear that that is bogus information and should not be done that way. but i think the image url in <> brackets is bogus information too, in plaintext. for text email clients for example, if the image is attached you can always view it with an external viewer, if you have an html part, e.g. pine can view that too and does the text conversion itself, and you can view images too. if i want to tell something meaningful in the text part, i'll have to use the alt tag. i don't beleive that we are losing info either, because in plaintext, the info shouldn't be the image url, but the alt and only the alt. if you think that the removal of the images url is a loss, then it's the same if there _is_ an alt. then we would have to convert to the alt text plus the image url, otherwise we have that one info but lose the other. i understand your points, but i think an <http://image.url> in something called "plaintext" is just annoying.

> i don't beleive that we are losing info either, because in plaintext, the info > shouldn't be the image url, but the alt and only the alt. Agreed, but we are talking about the case where there is none. Maybe the author just forgot it or is not aware of it. > if you think that the > removal of the images url is a loss, then it's the same if there _is_ an alt. If there is an alt present, then I assume that the author knows what alt means and provides a full text alternative. At least, I have a hint that there *was* an image. Anyways, if I am alone with my opinion, I'll just shut up.

I still don't understand why we want to do something different in the HTML->TXT converter than in the HTML->GFX converter (i.e. Layout). In comment 38, when I said "It was decided to not use the src attribute to create the alt text", I meant the alternate text used in rendering, not the value of the alternate text. Please reread comment 38 again bearing this in mind.

Hixie, oh ic. Well, in the case of Layout it probably makes no sense to offer a URL, because the image (probably) isn't loadable anyways. In our case, the user can manually load the image. I am not aware of any functions that give me a text representation for an image. But the previous comments IMO show that the applications aren't identical enough in theory to advocate using the same code.

Please excuse the fact that my comment could be long. I haven't touched this bug in a while and it appears people have decided that means my opinions no longer matter. when Julien Cegarra wrote Comment #23 at 2001-10-18 05:44 it became clear that Julien had not read my comment #16 or akkana's response, comment #17. various points to rossi@telnet.at * images aren't going to be attached so the only options are relying on title, alt, url, and the text/html part. The text/html part will not be present in many instances, the title and alt parts will not be non empty if the user is composing mail and doesn't understand that alt might be essential if the message will be collapsed to text/plain * This /text/ is still considered text/plain, even though it has three slashes and other elements of punctuation. * while rossi continues to refer to the format as plaintext the format for emails is message/rfc-822 or something, and does not explicitly prevent people from sticking UUEncoded data, ascii art, urls, icq uins, irc taglines, portions of what could be a vcard, or a homepage. I still agree with Ben B's views. Oh well, so much for my long comment.

timeless: > ...if the user is composing mail and doesn't understand that alt might be > essential if the message will be collapsed to text/plain 1) with that message appearing on each insert of an image, _every_ user understands that it is recommended to add an alt attribute - and as i said: i agree that this text could be changed to something even more "aggressive". 2) composer in current state will add an alt="" if the user enters no value for alt - so composer and this bug don't have no direct connection, as there will never be a <http://example.com> in a composed mail (or as text saved composed page) anyway in current state. > This /text/ is still considered text/plain, even though it has three slashes > and other elements of punctuation. > ... the format for emails is message/rfc-822 or something, > and does not explicitly prevent people from sticking UUEncoded data, ... fun fun. i didn't argue about the technical definition of plaintext, of course we can use "[s] value [s]" as a representation for a submit button too. i just don't think that an image with no alt tag (which again never happens in composer) is ever interesting as it's url - in plaintext. but i will make another patch soon which is only for copy&paste and window.getSelection() because i really want this in 1.0 . or are there any arguments against copy&paste not showing an image as it's url too? (which is basically the same because again: composer always adds an alt="")

For copy paste the URL are *SO* %!$£*!£$*&#!@#%! annoying that we really REALLY should remove them, I totally agree. That is in fact what this bug was originally about, and nobody (as far as I can tell) has suggested WONTFIXing this bug. However, changing the code so that it does one thing for copy/paste and another for text conversion unrelated to copy/paste is pure bloat if the second code path is never used, as you seem to suggest. If the editor does indeed always add an alt attribute (and it certainly should; it's a standards-compliance bug if it doesn't) then what is the point of the second code path? My review of the second patch still stands. BenB: The function in question is in nsCSSFrameConstructor and is called GetAlternateTextFor(). It uses the alt attribute, the value attribute, or the default submit string respectively, and if all are missing it defaults to "". That function is the result of several years of fine tuning.

> However, changing the code so that it does one thing for copy/paste and > another for text conversion unrelated to copy/paste is pure bloat if the > second code path is never used, as you seem to suggest. This code path (non-copy) will be used when bug 42441 is fixed. If it isn't used at the moment, that is merely a coincidence and nothing that would matter. > It uses the alt attribute, the value attribute, or the > default submit string respectively, and if all are missing it defaults to "". > That function is the result of several years of fine tuning. But I think you also use a "broken-image" icon. We have nothing like that in plaintext, which is my main point.

(Sorry, I missed rossi's comment) > are there any arguments against copy&paste not showing an image as it's url too? I have none.

We do not use a broken image icon except in quirks mode. Secondly, I see no reason why bug 42441 should result in a page that looks different from the page rendered graphically. If it does, then I *definitely* see no reason for it to look different than what Lynx does, and Lynx certainly does not embed random URIs into the middle of paragraphs. I would be STRONGLY against making bug 42441 display the URI of images in the middle of the pages it output, *especially* considering the *mess* that would make. Have you actually TRIED using copy and paste on web pages these days? It's totally useless because of this bug! Why would Save As Text want to be as useless as Select All, Copy is now?

> Secondly, I see no reason why bug 42441 should result in a page that looks > different from the page rendered graphically. Plaintext has different customs from graphical output. For example, <strong> is usually rendered as bold in graphical browsers, while in plaintext, we usually use *stars* to emphasize something. > If it does, then I *definitely* see no reason for it to look different than > what Lynx does, and Lynx certainly does not embed random URIs into the middle > of paragraphs. Lynx is an interactive application. It could for example display "[Image]", and, when you activate it, download the image. We can't do that. > Have you actually TRIED using copy and paste on web pages these days? I just did it. I tried cnn.com, because it's a major site. Some observations: <example type="textcase" src="http://www.cnn.com"> Updated: 07:58 a.m. EST (1258 GMT) -- 8 January 2002 <http://www.cnn.com/images/0110/header.war.against.gif> [image] Sen. Bill Nelson, D-Florida, meets <example> Here, you see the result of 2 images: - "War against Terror". It appearantly has no alt, that's why the URL is shown. The URL gives good hints at what the image was supposed to say. - Picture with politician. The source has |alt="image"|. <example> Search the TIME Archive » <http://i.cnn.net/cnn/images/time/1101020114cnn.gif> 4 Risk-Free Issues </example> Here, the URL doesn't say much and is not important either, but it gives a hint that this was an ad. A lone "4 Risk-Free Issues" might be more confusing. There is only one other image url in the output: <example> ON CNN TV CNN Program Schedule » <http://www.cnn.com/CNN/Programs/includes/showbox/images/2002/01/ventura.thumbnail.ap.jpg> American Morning with Paula Zahn: </example> Next page I tried was <http://finance.yahoo.com>. There is only one image URL, namely <http://us.a1.yimg.com/us.yimg.com/a/1-/flash/compaq/powerby_1008_76x24_trans.gif>. Not important, but gives good hints at its meaning and purpose. Then I tried <http://disney.go.com/disneyatoz/disneyana/>. Disney is not exactly known for its internet-savyyness, so maybe we see some bad output here. At the beginning, we have <example> <http://disney.go.com/globalmedia/chrome/v4.2/disney_purple.gif> > Entertainment > Disney A-Z <http://disney.go.com/globalmedia/chrome/v4.2/sitemap_purple.gif> <http://disney.go.com/globalmedia/chrome/v4.2/search_purple.gif> <http://ad.disney.go.com/ad/sponsors/compaq/comp-log0118.gif> </example> Again, the URLs give hints at the purpose and meaning. Note that there are no text alternatives at all provided. At the end, there is a <http://a1964.g.akamai.net/7/1964/24/c9de849c20e911/disney.go.com/globalmedia00/small_footer/small_footer_purple.gif>. Not very useful. So, with this imperfect test, I can't say that it is "totally useless" or a "mess". In fact, I think that the image URLs we saw where all in all more helpful than not. Of course, the result might differ on other pages.

You can't say it's a mess?! Your examples brilliantly demonstrated why I think we should not show the URI in any case, copy and paste or save as. I could not have done better myself.

For example, in the case of <http://www.cnn.com/images/0110/header.war.against.gif>, this is the only sign that there ever was a header. With the proposed patch, there'd be none. I think it is pretty bad to *completely* remove a header (maybe not in this case, but in others). I'll attach the whole CNN page as text, created via copy&paste, so you can put the snipplets into perspective. I really don't think it's a mess (at least, not because of the image URLs :-) ), but maybe we just disagree. How about URLs as footnotes and placeholders for the images, like <example type="proposal"> Image[2} [...} [2] http://www.cnn.com/images/0110/header.war.against.gif </example> But we'd have to I18N this then.

Hixie: > However, changing the code so that it does one thing for copy/paste and another > for text conversion unrelated to copy/paste is pure bloat if the second code > path is never used, as you seem to suggest. Just a note that we already have two codepaths, "formatted" and "unformatted", where "unformatted" is intended for use with copy/paste (where you want the content in an easily digestible form) and formatted is for things like translating html mail to plaintext (where you want to try as hard as possible to make the plaintext look like the html). They are both used today, and there isn't much bloat associated with it: one output flag and a few if (flag) return early statements in the plaintext serializer.

Akkana: I have nothing against having multiple codepaths, when they are all used; I was merely pointing out that dead code is bloat (almost by definition). BenB: In attachement 63973 the <uris> seem to me to be more of a distraction that anything. I honestly don't see why someone would care whether or not there were images without alt texts in the page they just saved. If they cared about the images I would think they would use the save as HTML option instead.

Ok, let's decide. We've heard both sides of the arguments, and I *think* there'll always be someone disappointed. However, there seems to be agreement that we won't insert the url when copying the html, and I want that fixed soon. The remaining issue is mail, I'll try to find out if anyone from mailnews cares one way or the other. Following that, we can either go with Rossi's patch, or add a if(mFlags & nsIDocumentEncoder::OutputFormatFlowed) before the code that inserts the URL. Personally, I'm more inclined to never copy the URL.

Peter, the case in questionis not mailnews, but Navigator in the future. Instead of removing URLs, maybe add a hidden pref with default off? Should be easy - we read some prefs anyway.

Bugscape Version: http://bugscape.netscape.com/show_bug.cgi?id=11699

hidden prefs are bloat. I am firmly of the opinion that we should not add any more hidden prefs unless we remove at least one existing hidden pref.

I am with Ian on this...a plain-text copy should be a plain-text copy. I don't want image references when I copy from mozilla/navigator and paste to a plain text edit field or app. Nothing, nada...just the text, please.

> hidden prefs are bloat. No, they are not. They are 3-5 lines of code and if they make people happy, this is a small price. > I am firmly of the opinion that we should not add any > more hidden prefs unless we remove at least one existing hidden pref. I am firmly of the opinion that the huge number of prefs are one of Mozilla's best features. Note that with bug 17199, any hidden pref might suddenly get a nice UI. Maybe let's better remove XUL. Only developers use it, anyway.

--> myself, after discussing with Nisheeth.

Past 0.9.8, moving forward.

BTW: I don't want to block this bug. If you think that the default behaviour should be changed, then fine. I disagree, but well.. Maybe we can have a mode to en/disable the output of links, both <a href> and <img src>.

I've following view about this bug: 1. If there is no "alt" with an image, that does mean that editor of the HTML wants nothing to be shown, if the image view is not enable. If the editor is concerned about the situation where the user may not be able to view, editor must set some value to "alt". 2. While copying an image and pasting to "HTML", we must include the "src" URL, which is what we are doing and not related to this bug too. 3. While pasting image from HTML -> Plain text, there is no meaning of carrying a URL along. Had it been something that the plain text editor could understand, there could be some sense but as this is "absolutely meaningless" for a text editor, we must not include it on pasting. 4. While attaching some images to a mail and sending it as "Plain Text", we might like to add the "src" URL as the value of "alt", which may be raised as a separate bug. With these facts I'll attach a patch soon, if this "sounds suitable to all (most) of us"...

tanu... i attached that patch 2001 12 08 ... it does exactly what you said.

Why not have a consensus about it and get that patch a super review !

Comment on attachment 60979 [details] [diff] [review] proposed patch (removes URL for all modes) sr=jst

Comment on attachment 60979 [details] [diff] [review] proposed patch (removes URL for all modes) a=shaver for 0.9.9. (Also marking hixie's review with the patch manager.)

marked fixed for rossi@telnet.at

Verified FIXED (my original testcase only) on all: 2002-03-14 (-08, -03) mac OS x 10.1.3, windows 2000 and redhat linux 7.2 builds.

*** Bug 119682 has been marked as a duplicate of this bug. ***

Continued (?) in bug 212177, "image alt text not selected on copy paste".