Closed Bug 66035 Opened 24 years ago Closed 22 years ago

Image urls are copied with text selection

Categories

(Core :: DOM: Serializers, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: stephend, Assigned: rossi)

References

()

Details

Attachments

(2 files, 1 obsolete file)

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 ???.
OS: Windows NT → All
Hardware: PC → All
No discussion needed.  They use images as spacers to seperate consonants. 
Marking IVALID.  Sorry guys ;-(.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
and..verified.
Status: RESOLVED → 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.
Severity: normal → major
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
Summary: Copying gets URL information when it should only get the definition. → Image urls are copied with text selection
`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
Assignee: mjudge → anthonyd
Status: REOPENED → NEW
Priority: -- → P3
Whiteboard: [nsbeta1-]
Target Milestone: --- → mozilla0.9.1
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
Assignee: anthonyd → brade
Target Milestone: mozilla0.9.1 → mozilla0.9
moving to mozilla1.0
Target Milestone: mozilla0.9 → 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
Assignee: brade → peterv
Component: Selection → DOM to Text Conversion
Keywords: nsbeta1
QA Contact: blakeross → sujay
Whiteboard: [nsbeta1-]
*** 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)
Target Milestone: mozilla1.0 → mozilla1.0.1
*** 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...
Attachment #60976 - Attachment is obsolete: true
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)
Attachment #60979 - Attachment is obsolete: true
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.
Attachment #60979 - Attachment description: correct proposed patch → proposed patch (removes URL for all modes)
Attachment #60979 - Attachment is obsolete: false
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.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0.1 → mozilla0.9.8
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.
Keywords: edt0.9.4
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.
Keywords: edt0.9.4
--> myself, after discussing with Nisheeth.
Assignee: peterv → tmutreja
Status: ASSIGNED → NEW
Past 0.9.8, moving forward.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
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
Attachment #60979 - Flags: superreview+
Whiteboard: needs check-in
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.)
Attachment #60979 - Flags: review+
Attachment #60979 - Flags: approval+
marked fixed for rossi@telnet.at
Status: NEW → RESOLVED
Closed: 24 years ago22 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
*** Bug 119682 has been marked as a duplicate of this bug. ***
Continued (?) in bug 212177, "image alt text not selected on copy paste".
Whiteboard: needs check-in
Assignee: t_mutreja → rossi
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: