44371 - [D&D]Link titles (and more) lost when dragging URLs to compose

Status: RESOLVED FIXED

(Core :: XUL, defect, P4)

Description

[Eli Goldberg]

* TITLE/SUMMARY
Link titles (and more) lost when dragging URLs to mail compose 

* STEPS TO REPRODUCE
0) Launch Seamonkey (with mail server/id information already populated)
1) View a web page containing titled links (e.g. <http://www.netscape.com>)
2) Open a new mail message. (File | New | Message)
3) Drag a link (e.g. "Job Search") to the mail message's content region.

* RESULT
 - What happened

On Mac OS, the link does appear, but with its URL as the link title (e.g. <http:/
/www.netscape.com/netcenter/careercenter/>), rather than its actual textual title 
(e.g. "Job Search")
 
On Windows, no link appears --- the URL is pasted in plaintext.
 
 - What was expected 

Link title should be maintained when dragged, and a link should remain a link 
when dragged.

* REGRESSION

 - Occurs On
        Mac OS, Win32 Seamonkey (6.30.2000 build)		

 - Doesn't Occur On
        Mac OS Communicator 4.73
        Linux Seamonkey (6.30.2000 Netscape build) --- drag operation fails, 
can't test		



* 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).

Comment 1

[Eli Goldberg]

QA Assigning to self. 

Nominating for NS Beta 2, per presence of "Links into mail compose" on PRD.

Comment 2

[Eli Goldberg]

Peter Mock noted that drag does work on Linux, I just dragged in a fashion that 
didn't work. (not exactly sure, will play with later) Behavior is identical to 
that of Windows.

Comment 3

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 4

[Jean-Francois Ducarroz]

reassign to Editor team.

Comment 5

[Kathleen :Brade]

The problem really lies in the data that the browser sends.  cc pinkerton; 
reassign to myself.  It may even be a duplicated of another bug.

Note:  this may need to get fixed by someone else since I'll be going on 
sabbatical soon.  Add helpwanted keyword.

Comment 6

[rubydoo123]

setting to correctness keywork and removing old keyword

Comment 7

[rubydoo123]

setting to nsbeta3+

Comment 8

[rubydoo123]

adding priority to status whiteboard

Comment 9

[Kathleen :Brade]

reassign to Ben since this fix will be in navigatorDD.js file; Ben, I'm going on 
sabbatical so I won't be able to fix this for 6 weeks.  Sorry!

Comment 10

[Ben Goodger (use ben at mozilla dot org for email)]

I'm already overloaded for nsbeta3. sorry. 

Comment 11

[rubydoo123]

going to assign this over to anthonyd. Anthony, Eli, Ryan and I have been able 
to reproduce this one. Just one tidbit -- if you d&d from mozilla browser to 
composer/mail compose it works just fine, if you d&d from 4.x, it fails.

Comment 12

[Eli Goldberg]

err, perhaps it fails even more 4.x ---> Seamonkey, but the bug described here 
occurs precisely as described (Seamonkey ---> Seamonkey.)

Comment 13

[rubydoo123]

really -- it works every time for me on win98 going from browser to mail or 
browser to composer

Comment 14

[Eli Goldberg]

well then, come by Eli-land and see what's the full story, since one person's 
inability to reproduce the bug does not negate its existence!

best,

eli

Comment 15

[Mike Pinkerton (not reading bugmail)]

well, i haven't tried to reproduce it, so therefore i cannot. does my ambivalence 
imply that this bug does not exist? I think it does ;) heehee

Comment 16

[rubydoo123]

who said anything about closing it out as wfm? yes, I am interested in seeing 
what you are doing <<wrong>> -- that's a joke

Comment 17

[anthonyd]

what exactly do we want with this?  do we want this to behave like 4.x does?

anthony

Comment 18

[Jim Roskind]

PDT thought that this functionality was very non-essential, and reduced the bug 
to P4

Comment 19

[rubydoo123]

making this a - and moving out to future based on b3/rtm criteria

Comment 20

[Kathleen :Brade]

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

Comment 21

[anthonyd]

setting milestone to 0.9, want to try and pick this up for 6.5
anthonyd

Comment 22

[anthonyd]

futuring.

anthonyd

Comment 23

[anthonyd]

removing nsbeta

Comment 24

[Charles Manske]

Removing milestone. I think this should be seriously considered for
 0.9.1 milestone.
This is what I think we should do: When copying a link to clipboard, we should
copy a string that is the "source (title)" text and append the url like this:
"The text user sees for link [http://www.mozilla.org/blah]"
Then when pasted into an outside app,you get both the title text and link.
In our apps, such as composer, we should examine the string to look for URLs and
convert to a real link:
<a href="http://www.mozilla.org/blah> The text user sees for link </a>
In browser, the string can be examined to use the URL for loading.
Similarly logical things should be done when copying into bookmark window, etc.

Comment 25

[Kathleen :Brade]

This bug probably belongs to blake (not Tony).  I've been wanting to fix it for a 
long time but I haven't had time.  :-(

Removing blocker bug since that's really just a duplicate of this bug.

Comment 26

[Kathleen :Brade]

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

Comment 27

[Blake Ross]

Stealing...

Comment 28

[Blake Ross]

Attachment: simple patch...

Comment 29

[Blake Ross]

The only change relevant to this bug is

       if (!htmlstring && urlstring)
-          htmlstring = this.createLinkText(urlstring, urlstring);
+        htmlstring = this.createLinkText(urlstring, titlestring);

If there's no titlestring, we default to the urlstring just before, so this is 
essentially the same thing.

Cc'ing alec for sr.

Comment 30

[Alec Flett]

sr=alecf

Comment 31

[Jason Kersey]

r=kerz

Comment 32

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 33

[Blake Ross]

Fix checked in.