Open Bug 44362 Opened 24 years ago Updated 2 years ago

Dragging or copy/pasting mailto: link from browser to To: field doesn't strip the "mailto:"

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

People

(Reporter: elig, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [patchlove])

Attachments

(1 file)

patch (with a few whitespace changes as well)
2.69 KB, patch
Details | Diff | Splinter Review 
* TITLE/SUMMARY
Dragging mailto: link from browser to To: field doesn't strip the "mailto:"

* STEPS TO REPRODUCE
0) Launch Seamonkey (e-mail server & id must be pre-populated in Preferences)
1) View a web page that contains a mailto: URL. (I used <http://www.prometheus-
music.com/contact.html>,
which is just a page on my personal web site.)
2) From the File menu, select "New", and then "Message".
3) Drag any e-mail mailto: link from the web page to the new mail message's "To:" 
field.

* RESULT
 - What happened

The "mailto:" portion of the URL isn't stripped as part of the drag operation, 
so, you have a To: address like
"mailto:feedback@prometheus-music.com". (The e-mail message did successfully 
reach its recipient.)

 - What was expected 

"mailto:" to be stripped, leaving the e-mail address.

* REGRESSION

 - Occurs On
        Mac OS Seamonkey (6.29.2000 Mozilla optimized build --- mail wouldn't 
launch using 6.30's optimized build)		
        Win32 Seamonkey (6.29.2000 Netscape optimized build [NT 4, Service Pack 
5])
        
 - Doesn't Occur On
        Communicator 4.73 (Mac OS)



* CONFIGURATIONS TESTED

- [Mac] Power Mac G4 (450 Mhz), 256 MB RAM (VM off), 1024x768 (Thousands of 
Colors), Mac OS 9.0

- [Win32] Vectra VL (266 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).
Hi, Scott --- Lisa thought you might want this one, if the actual problem is 
occurring on the drag-receipt side. If not, just say so, and I'll punt it to a 
browser engineer.

<BTW, sorry about the hard line breaks. editor now properly configured.>
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Seth requested that this go to Jean-Francis, when I was visiting to inquire about 
another bug.
Assignee: mscott → ducarroz
QA Contact: jrgm → elig
moving to future milestone.
Target Milestone: --- → Future
Status: NEW → ASSIGNED
QA Contact: elig → jrgm
OK, this is a three-liner (including the comment :-). I've solved this 
by chopping "mailto:", if present, off any links we drag out of the 
browser content window. This should cover the majority of cases.

Attaching patch, looking for review from ducarroz.

Gerv
Assignee: ducarroz → gervase.markham
Status: ASSIGNED → NEW
Keywords: mozilla0.9, mozilla1.0, patch, review
Target Milestone: Future → mozilla0.9
ducarroz (or blake): Any chance of a review for this 3-line JS patch? :-)

Gerv
Hmmm....assuming we want to strip this everywhere we drop it, r=blake.  I'm 
wondering if some apps (even us) would use the mailto: prefix as an indicator 
to open a new message form, or something.  (The original report seems to ask 
that we strip it when dropping into the To field, in which case we'd only want 
to handle this on that end).  Fine with me either way.
We don't seem to accept a drop (of a mailto:, anyway) on any part of the mail 
window or the browser content area. <shrug> I say we fix this for the really 
common case and, if people complain, this is an easy patch to back out, and we 
can think again.

Gerv
no! this is an incorrect fix. the fix is to fix the mail code to correctly
handle mailto: links - mailto: should not be hard coded into the content area
drag code.
Alec: why?  for the reason I said?
But what happens if I want to drag to a document I'm writing, or another email 
app? I would say that the normal use case is to want the email address, not the 
entire link.

We could fix up the mail window as well :-)

Gerv
no, then the dropped-on application should be grabbing the text/unicode flavor,
not the text/x-moz-url flavor. all the information is stored in the
nsTransferable object.
http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/contentAreaDD.js#146

basically, all flavors are stuck in the object that gets dragged
urlstring, as "text/x-moz-url" = the raw URL, should ALWAYS contain a mailto:
link
htmlstring, as "text/html" = an html fragment that would get inserted into a
rich text document
titlestring, as "text/unicode" = the user-visible representation of the string

alecf: So what you are saying is that we should be chopping mailto: off the 
text/unicode version instead of the -x-moz-url version? That seems just as easy, 
so we could certainly do that.

Gerv
no... the mailto: will not be in the text/unicode flavor

the ondrag code is correct in nsContentAreaDD.js, which is what I've been saying
all along.

the special mailto: handling should be handled by the consumers, such as the
mail compose window - if you drag a mailto: link, then the mail window should
ask for the x-moz-url flavor, and chop of the mailto: if one exists.

Er... I may be reading this wrong, but surely the mailto: will be in 
text/unicode?

It's an A tag, so isAnchor will be set to true. If this is the case, 
text/unicode gets set to the urlstring. 
aXferData.data.addDataForFlavour("text/unicode", isAnchor ? urlstring :  
titlestring);
The urlstring is found when you do:
urlstring = this.getAnchorUrl(draggedNode);
which returns the value of node.href, i.e. including the mailto:.

Is there a tool where you can see what it is you are dragging?

Gerv

mailto: links can get pretty complicated.  For example, clicking this url might 
set you up to send mail to foo@bar.org and to me, cc'ing nobody@mozilla.org, 
with a subject of "mailto links":

mailto:foo@bar.org?to=Jesse Ruderman <jruderman@hmc.edu>&cc=nobody@mozilla.org
&subject=mailto links

The mail program that you drag to should see the "mailto:" so it has a chance 
to figure out what it's supposed to do.  (By the way, what should happen if I 
drag that link into the CC field of a message I'm composing?)
This is not just about dragging to Mozilla Mail, but other mail programs, text 
editors, documents etc.

I think it's reasonable to state that when a mailto: link is dragged to anywhere 
except for a mail window and perhaps a compose window, people want the email 
address, not the mailto link. I am looking for a way to make that happen. My 
idea is that the Mail and Compose windows should be asking for x-moz-url (and so 
see mailto:) and a text editor or arbitrary app should get the text/unicode 
version (and so just get the address.)

Gerv
Gerv: that's not the way things work nor the way they should work.

ideal world. I drag a link to a random app.
case a: it's a mail app and recongizes urls, it requests x-moz-url
case b: it's a text app and recognizes text, it requests text/unicode

case z; I don't want the default handling, and my app is smart, so i right drag 
the link to the app. when I release the app gives me a list of the different 
available flavors and lets me pick the one i wanted.
timeless: I'm not with you. What are you, in fact, saying about the best fix for 
my problem (as articulated above and as represented by this bug)?

Gerv
bingo!
thank you timeless
this is not complicated.

the drag code should NOT have ANY special handling for mailto:

it's up to consumers, such as the mail compose window

and no, generic text fields should not try to strip mailto: on drop.


I totally aggree with alecf. BTW, sorry to jump late on this bug...
Alecf: I don't want to push this, but you said:
"no... the mailto: will not be in the text/unicode flavor"

This is _not_ true, according to my reading of the code (outlined above.) Am I 
wrong?

Mailto: links are not like other links, because they are used by humans in a 
different form to that which they are used by machines. 

Gerv
all link types, not matter what the schema, are used by humans and computers. I
will continue to reject any and all schema-specific handling in the content area
drag code.
Target Milestone: mozilla0.9 → mozilla0.9.1
Having thought about this, I have no interest in dragging mailto: links to
Mail/News. 

Dragging them to other apps, such as my editor, and having them show up as email
addresses would be really handy, but as I can't change their drop code and I
can't change Mozilla's drag code, this obviously won't be possible. :-(

Reassigning to component owner for a fix to the Mail/News drop code.

Gerv
Assignee: gervase.markham → trudelle
To quote alecf: "it's up to consumers, such as the mail compose window"

-> MailNews, Composition :-], and clearing milestone for owner to set
Assignee: trudelle → ducarroz
Component: XP Toolkit/Widgets → Composition
Product: Browser → MailNews
QA Contact: jrgm → esther
Target Milestone: mozilla0.9.1 → ---
Re-assigning to varada
*** Bug 83068 has been marked as a duplicate of this bug. ***
varada, can you check if the patch still works and if yes, check it in. Thanks
Assignee: ducarroz → varada
Target Milestone: --- → mozilla0.9.6
moving to 1.0
Target Milestone: mozilla0.9.6 → mozilla1.0
Target Milestone: mozilla1.0 → Future
*** Bug 110219 has been marked as a duplicate of this bug. ***
Blocks: 154188
Depends on: 157027
*** Bug 166067 has been marked as a duplicate of this bug. ***
Regardless of whether 'mailto:' is pasted or not, IMHO MailNews should ignore
the 'mailto:' at the beginning of an address field and send to the address
following it. 'mailto:' should also be ignored for purposes of address
completion with the drop-down list.
Comment on attachment 28348 [details] [diff] [review]
patch (with a few whitespace changes as well)

The fix should be on the mailnews compose side. Also, it should take care of
the past case.
Attachment #28348 - Flags: needs-work+
varada, any chance you could do something soon for that?
Keywords: patch, review
I have a patch for this but am waiting on 155796(blakeross)that the event
handler doesnt fire fon ondragdrop. If you want me to go ahead and check the fix
in on our side I can do that.
Would be nice to have someting in the next version. Does your patch takes care
of the past case?
taking all of varada's bugs.
Assignee: varada → sspitzer
Just ran into this bug. Is someone still giving attention to it?
Product: MailNews → Core
Confirm the problem still exists in TB 1.5.

Changed the title slightly to reflect that this isn't entirely bound to DnD, but effects people cutting and pasting into the To address as well.

Note this should probably apply to CC and BCC as well as To.

Looks like this bug is in a coma so adding "helpwanted". Also adding "polish" since this is trivial to fix but has probably been annoying a lot of people.
Keywords: helpwanted, polish
Summary: Dragging mailto: link from browser to To: field doesn't strip the "mailto:" → Dragging or copy/pasting mailto: link from browser to To: field doesn't strip the "mailto:"
Cannot paste to comment section of yahoo email,was able to do it when on internet express
Re: Comment #42 From Roy  2006-07-12 13:52 PDT  [reply] -------

Roy, I think your bug is not the same as this one, which is now very much specifically about how the event is received in the MailNews composition (and possibly related) windows.

If I'm reading "Yahoo Email" correctly, and you are referring to a website, with regard to some earlier comments I believe this is most likely a seperate bug relating to the widget set not handling drop events for mailto: links properly?

I could be wrong on that but it's the best place to start. Refile as a seperate bug.

-------------------

While I have this bug open again, confirming the bug still exists when dragging mailto: links from Firefox version 1.5.06 to Thunderbird version 1.5.0.5 (20060719).

Draggin the "Eli Goldberg" link from the bugzilla interface to a compose To: field gives me.

To: mailto:elig@formerly-netscape.com.tld,Eli Goldberg

This identifies an additional subtlety, when DDing a mailto: link to the To: field it should probably paste "Eli Goldberg <elig@formerly-netscape.com.tld>".

Also confirm it still doesn't strip mailto: from a text cut and paste either.

And as per the following...

  Assigned To: (not reading, please use sspitzer@mozilla.com
               instead) <sspitzer@mozilla.org>

... reassigning from sspitzer@mozilla.org to sspitzer@mozilla.com.
Assignee: sspitzer → sspitzer
Assignee: sspitzer → nobody
QA Contact: esther → composition
Product: Core → MailNews Core
I can't follow all the comments here, so I don't know if this is the right place to report this.

When I copy a 'mailto:' link and paste it into a text editor, Word, email body, etc, it doesn't strip out the 'mailto:' prefix and you end up having to do it manually. 

Is that the desired behavior?

xref fixed Bug 32358 - changes to context menu for mailtos

should be easy to fix?

Flags: needinfo?(acelists)
Keywords: helpwanted, polish → regression
Whiteboard: [patchlove]
Target Milestone: Future → ---
Flags: needinfo?(acelists)
Priority: P3 → --
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: