User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081203 Shiretoko/3.1b3pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081203 Shiretoko/3.1b3pre In Firefox 2 and 3.0, you could drag the icon to the left of a location bar into a formatted text region of another app and have a hyperlink pasted into the drop location with the display text of the link being the HTML Page Title. Since the introduction of the new tab drop behavior where tabs dragged out of a tab bar create new windows, this behavior is broken (or at least changed for the worse for me). It’s a very important time saver for me to be able to drag links from web pages into already composed emails and documents. So this feature is very important for me and I suspect others. Reproducible: Always Steps to Reproduce: 1. Click the icon to the left of the Location bar 2. Drag it into a formatted text editing region such as a Thunderbird Mail Compose window 3. Release the mouse Actual Results: Actual Result: A link is pasted with the full URL of the html page as the displayed text Expected Results: Expected result: A link is pasted into the drop location with the title of the html page as the display text (this is how it works in v3.0 Firefox) So current behavior is close but the title should set as the display text instead of the url. bug 451911 is similar but different I think. Somewhat releated to Bug 428096

I have a hunch this change in behavior may have been triggered by the patch for bug 428096 (landed on 2008-11-06 around 5pm PST). If I'm right, the 2008-11-06 mozilla-central nightly won't have this problem, but the 2008-11-07 nightly will have it. Please download these nightlies and test for this: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/11/2008-11-06-02-mozilla-central/firefox-3.1b2pre.en-US.mac.dmg ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/11/2008-11-07-02-mozilla-central/firefox-3.1b2pre.en-US.mac.dmg

By the way, I've confirmed this.

This does sound like my bug 468892 - I want to also note in the comments in this bug that not only does the wrong thing get dropped but the font it drops with is wrong (overrides what it should be) - see the movies I included with that bug. I also want to stress that the same font doesn't always appear -- with links from, say, NYTimes, the font is very big, but some sites result in very tiny text that's hard to read.

(Following up comment #2) Sorry, but I'm *not* able to confirm this. (I somehow got confused.) Even with FF 3.0.4, dragging from the icon to the left of the location bar *doesn't* (in my tests) result in a link "pasted into the drop location with the title of the html page as the display text". The destinations I tried were new mail messages created in Thunderbird 2.0.0.18, a recent Shredder nightly, and Apple Mail. Instead what I got was the full text of the page's URL, sometimes formatted as a link (Apple Mail), and sometimes as plain text (Shredder and Thunderbird 2.0.0.18). In all cases I set my mail program to compose mail in HTML/Rich-Text.

I took a quick look at this in Pasteboard Inspector with 3.1b2 and 3.0.3 that I have lying around. In 3.1b2, public.html and Apple HTML pasteboard type both contain the URL as the text inside the <a></a>. (Dragging a link from a web page does properly populate the <a></a> text with the text that's inside the <a></a> on the actual page.) In 3.0.3, we don't export any HTML formats, and, indeed, dragging the site icon to some sort of rich-text-accepting application (I tested both TextEdit and Colloquy's message-entry field) produces a link with the page title as link text. (I'm not sure why Mail.app is broken here, but it's pickier about what it accepts My working theory on this is that these applications prefer to accept a "rich text" flavor (RTF or HTML) and use that flavor when it exists. If an HTML or RTF flavor does not exist in the drag, the apps fall back to putting together the link themselves from 'url '/public.url and 'urln'/public.url-name. Since Firefox 3.1b2 now exports HTML, the apps prefer to use that flavor. Unfortunately, for drags of the site icon, the HTML flavor is "broken" in 3.1b2. Is there some way to check to see if the source of the drag is a site icon and in that case make sure to populate the "link text" with the page name? Alternately, is it possible to disable creation of HTML flavor when the source of a drag is a site icon? Of course, that assumes bug 428096 is the cause; it would be good if someone would download the builds from comment 1 and confirm that regression range.

I did a test on the two builds from comment 1. Results are below. I've also attached an RTF file which, while not exactly the same output, demonstrates the results. The attached also shows results for dragging html and for copy/paste of html in case this is helpful in understanding the issue. To summarize Drag of the Location bar icon result in: - For the 11/06 build: * TextEdit: Hyperlink with title (e.g. "My Site" as hyperlink) * Apple Mail and Thunderbird 3.0b1pre: Plain text of link - For the 11/07 build: * TextEdit, Apple Mail and TBird 3.0b1pre: Hyperlink WITHOUT title (i.e. http://mysite/file.htm) So it would seem things got a bit worse for apps TextEdit but overall more consistent. Let me know if you need further tests or want me to verify a change on a private build or something.

Thanks for doing that. Note to anyone who makes a patch: I'd be mostly happy if any patches for this bug would at least fix the infuriating tendency of the browser to decide that my chosen font (or no font at all) isn't good enough and that it has to override my settings with font size/face changes, even if the missing page title isn't restored. I don't se why the 11/06 (and earlier) behavior was broken -- it seems to be ideal to me to have a hyperlinked page title where reasonable and the link itself where not (e.g. in an email, which is normally a plain-text document).

(In reply to Steve McMillen from comment #0) > Steps to Reproduce: > 1. Click the icon to the left of the Location bar > 2. Drag it into a formatted text editing region such as a Thunderbird Mail > Compose window > 3. Release the mouse > Actual Results: > Actual Result: A link is pasted with the full URL of the html page as the > displayed text I see the same on latest nightly 2013-07-15 on Win 7, Mac OS X 10.7.5, but isn't this the expected behavior ?

> but isn't this the expected behavior? I don't know. And judging by the different behaviors reported in comment #6, it'd be difficult to decide. For what it's worth, I tried comment #0's STR with both Firefox 22 and Safari as the source, and a Thunderbird mail compose window as the destination (on OS X 10.7.5). In both cases I got the plain text of a link -- not a hyperlink.

(In reply to Steven Michaud from comment #10) > In both cases I got the plain text of a link -- not a hyperlink. You have to check first 'compose emails in html format' and then you'll see the hyperlink. Tested also with Apple Mail client. It's the same behavior since FF 4 - 25 - hyperlinked. FF 2.0, 3.0, Safari, Chrome, Opera, IE (last 2 tested on on Win) paste only the plain text of the link. Anyway, no browser use the behavior described in comment 0 (which I also cannot reproduce).

I finally got it. This bug is all about TextEdit, Adium (in the duped bug) and possible other apps but not email clients. I confirm the range in comment 1. Still broken in 22 release, 25 nightly.

Reproducible Version 47.0.1 Build ID 20160623154057 User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0