Closed Bug 315370 Opened 19 years ago Closed 18 years ago

text Copy/Paste from Firefox to Outlook will be created as attachment

Categories

(Core :: Widget: Win32, defect)

Product:
Core
Component:
Widget: Win32
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: sebastian.sjoholm, Assigned: David.R.Gardiner)

References

Details

(Keywords: fixed1.8.1, regression)

Attachments

(7 files, 3 obsolete files)

NT Clipboard File after copying first sentence in comment 17
4.12 KB, application/octet-stream
Details
Results of unix 'strings' command on attachment 206097
953 bytes, text/plain
Details
ClipSpy.Firefox.1.0.6-Gecko-20050716
9.66 KB, image/jpeg
Details
ClipSpy.Firefox.1.5-Gecko-20051111.jpg
17.28 KB, image/jpeg
Details
Don't cause UniformResourceLocator flavour to be added to clipboard dataobject (against trunk)
3.33 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review
Don't cause UniformResourceLocator flavour to be added to clipboard dataobject (against 1.8.0 Branch)
1.96 KB, patch
dveditz
: approval1.8.0.4-
dveditz
: approval1.8.0.5-
Details | Diff | Splinter Review
Don't cause UniformResourceLocator flavour to be added to clipboard dataobject (against 1.8 Branch)
4.26 KB, patch
mark
: review+
roc
: superreview+
roc
: approval-branch-1.8.1+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

If I copy a selected text from Firefox (any website, example www.mozilla.org) and paste in Outlook (Outlook 2000 SP-3) new mail (formatted as 'plain text') it will be added as a new attachement.

If the email is 'html format' or 'rich text' format the text will be pasted properly.

Reproducible: Always

Steps to Reproduce:
1. open webpage (www.mozilla.org)
2. select text in webpage, and copy
3. paste in outlook email (email as 'plain text').

Actual Results:  
file attachment

Expected Results:  
paste plain text in message, this was working in version 1.0.x

This is similar to the one explained at Bug 311020.
Same problem for me on Windows XP profesional sp1 with outlook 2000 and Firefox 1.5 RC2. This is a regression since it was perfectly working in FF 1.0.7
(In reply to comment #1)
> Same problem for me on Windows XP profesional sp1 with outlook 2000 and Firefox
> 1.5 RC2. This is a regression since it was perfectly working in FF 1.0.7
> 

If you set your e-mail application (like Outlook 2000) to html-mail and paste from a webpage, it will work 'normally'.

This is because if you paste HTML from the webpage, it will now be HTML in Moz FF 1.5, thus it will become an attachment in an Outlook plain-text e-mail.

I'd prefer the previous behaviour also.
greetz,
   Leen - some tester.
Oh god, I'm confirming the HELL out of this issue. This is easily one of the biggest pains I've experienced with Firefox 1.5. I'm having to copy from the browser, paste into notepad, copy from notepad THEN paste to Outlook. It's killing me.

I can understand some people wanting this functionality, but for the love of god please make it an option that can be disabled.
Status: UNCONFIRMED → NEW
Ever confirmed: true
How is this Firefox's problem? We're handing Outlook the clipboard data as text/html (which is what it should be). It's up to Outlook to do what it wants to with the data.
Works fine for me, using Outlook 2003.
(In reply to comment #4)
> How is this Firefox's problem? We're handing Outlook the clipboard data as
> text/html (which is what it should be). It's up to Outlook to do what it wants
> to with the data.
> 

Because up until 1.5 it has been working as it should, and because every other application, including Internet Explorer, also continues to work as it should.

I'm of the opinion that it should NOT be sending as formatted html by default. If you copy text, it should copy text as text, regardless of its formatting. For the people that actually want this functionality, there should be an option in the preferences to the effect of "Retain formatting when copying text to clipboard." 
(In reply to comment #6)
> Because up until 1.5 it has been working as it should, and because every other
> application, including Internet Explorer, also continues to work as it should.

On the same machine, with the same configuration, 1.0.x works but 1.5 doesn't? If so, can you narrow down a regression range?

> I'm of the opinion that it should NOT be sending as formatted html by default.
> If you copy text, it should copy text as text, regardless of its formatting.
> For the people that actually want this functionality, there should be an option
> in the preferences to the effect of "Retain formatting when copying text to
> clipboard."

This is somewhat orthogonal to this bug, but I agree! Unfortunately I think that that opinion puts you in the minority. Standard practice in most apps I've dealt with is to default to "rich formatting" and provide a "paste as unformatted" function. People apparently like strange fonts and flashy colors.
> On the same machine, with the same configuration, 1.0.x works but 1.5 doesn't?
> If so, can you narrow down a regression range?

Same machine, same configuration. Windows 2000, Outlook 2000. The only change was the upgrade from Firefox 1.0.7 to 1.5. 
 
> This is somewhat orthogonal to this bug, but I agree! Unfortunately I think
> that that opinion puts you in the minority.

I don't think that's the case. In addition to the comments in this bug along with the mere fact that it has been filed, it has also been discussed at length on many other sites. The consensus is that this behavior is not wanted.

"When I copy text I want to copy the text. It's simple. But not in firefox, oh no. If I select text that's also a link then it copies some sort of bizarre windowsy link object, becuase that's obviously what I wanted. And then to add more hate when I paste this into a plain text message in Outlook it turns the link into an attachment." 
-- http://struan.hates-software.com/2005/09/22/49ab48ab.html

"Presumably he means the one where trying to copy and paste text from webpages sometimes results in all sorts of HTML and javascript code being pasted in with it, even though it's source and not the actual text you want."
-- http://www.dslreports.com/shownews/66461

"I don't know if this is related, but I'm writing an e-mail in Outlook, and when I try and copy something from a page that I'm looking at in Firefox (as in, a line of text) and I try and paste it in, Outlook automatically attachs an .html file and doesn't just paste plaintext into my e-mail like I want it to. However, if I do the same thing with IE it works fine."
-- http://forums.somethingawful.com/showthread.php?s=&threadid=1735836&pagenumber=6 (You won't be able to see this one unless you're an SA forums member.)

"Copy/Paste: I want the text, only the text. No the styles, not the url, not whatever formatting that was originally there."
-- http://www.lifehacker.com/software/ask-the-readers/ask-lifehacker-readers-what-are-your-top-computing-peeves-135013.php (Unrelated to Firefox specifically, but still relevant to this bug.)
Summary: text Copy/Paste from Firefox to Outlook will be created as attachement. → text Copy/Paste from Firefox to Outlook will be created as attachment
*** Bug 311020 has been marked as a duplicate of this bug. ***
*** Bug 319117 has been marked as a duplicate of this bug. ***
Confirming here:

Outlook 2000 SP-3
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Firefox 1.5 is GREAT, but this issue is very annoying. I write mail strictly in plain text, and thus cannot paste any content from webpages!! This worked fine in Firefox 1.0.x.

Also, it works fine with Outlook 2002 and 2003, which I tested on different machines.

Thanks!
If Outlook 2002 and 2003 work correctly, it is a bug in Outlook 2000 (why am I not surprised?). Given how prevalent that client is, it would be a good idea to have an option in prefs.js to revert to the old behavior.
The "old behavior" hasn't been identified, as far as I can see, so discussion of adding a pref to revert to it is fairly premature. Ideally someone who sees this problem would use the builds at http://archive.mozilla.org/pub/firefox/nightly/ to narrow down a regression range.
Workround if you need info pasted into MS Outlook 2000 e-mail :

Copy from website
Paste into MS Word
Copy from MS Word
Paste into MS Outlook 2000 e-mail

How soon before this bug is fixed? It's a pain...

Regards

Jim
Just to clarify this - people are stating that the attachment is a .htm file. That is not the case. The attachment is an .url shortcut to the internet addresses where the text was pasted from.

With the "old behavior", was unformatted text pasted even into Word documents or html e-mail messages? I don't think so, but will look at it tomorrow with FF 1.07.

If it is a bug in Outlook 2000, it should also be submitted to Microsoft, but what chance is there that it would be fixed?
I'm having same problem.  copy text from website using Firefox 1.5, paste into Outlook e-mail, and it is an attachment, not copy of text.  Happens every time.
Can someone please clarify the present actions of Firefox 1.5 with respect to the Clipboard? (never mind Outlook for my question) I do not have a clipboard viewer.

My understanding is that applications can copy data to the Clipboard in multiple formats. Then other applications can take a look at which formats the Clipboard has, and decide which data to use.

When someone has HTML text selected and presses Ctrl+C, I am guessing that Firefox is copying both the plaintext to the Clipboard as well as the URL of the page in question. Is this correct? I can understand the former, could understand if Firefox were posting the HTML within the copied selection, but don't understand why a URL would be copied to the clipboard.
I used c:\winnt\system32\clipbrd.exe to generate this dump.  According to google, this program comes standard on win2k and winxp.

I selected the text "Can someone ... the Clipboard?" and copied it to the clipboard.  Confirmed that it produced the URL-attachment in outlook, and then used the "save as" option in the clipboard viewer to generate this file.  I don't know much about the file format, but opening it in emacs, it does look like it's a lot more than just the text that I selected.
> I used c:\winnt\system32\clipbrd.exe to generate this dump.  According to
> google, this program comes standard on win2k and winxp.
> 
> I selected the text "Can someone ... the Clipboard?" and copied it to the
> clipboard.  Confirmed that it produced the URL-attachment in outlook, and then
> used the "save as" option in the clipboard viewer to generate this file.  I
> don't know much about the file format, but opening it in emacs, it does look
> like it's a lot more than just the text that I selected.

Appreciate the help (clipbrd.exe is on my computer as well), but let me clarify what I'm looking for & why I'm asking.

I'm looking for a clipboard viewer (and clipbrd.exe does not appear to do this) which is a programmer's tool to enumerate the different formats of data placed on the clipboard. Windows allows data to be placed on the clipboard in multiple formats. Applications pasting from the clipboard can use whichever format(s) they feel are appropriate. I am not positive but I believe there may be ordering / prioritizing of data pasted to the clipboard. Depending on what Overlook, I mean Lookout, I mean Outlook, does with the clipboard, there may be an easy way to change Firefox's clipboard code so that it makes plaintext be the priority or first format. If one of those formats is a URL, I question why it's being added. A programmer's clipboard viewer would be able to enumerate the formats & answer these questions. (Or maybe someone could point out where in the Firefox code the clipboard copy is being used, I'm horrible at navigating through the source tree.)

If there's no way to fix this without disabling one of the clipboard formats, then I agree there should be an option to disable whatever the hell it's doing. Outlook is another piece of software that Mozilla has no control over, but so many of us are stuck with it & the annoyance factor of this "bug" is EXTREMELY high. Whatever Firefox 1.0 did with the clipboard is highly preferable.

I am not at all familiar w/ Firefox code, only vaguely familiar w/ Windows API, and don't have any free time to explore further, but just want to point these out. (See EnumClipboardFormats in the Windows API.)
Yeah, I figured that dump wouldn't be supremely useful, but thought I'd attach it anyway in case it might ring a bell for someone.  I guess I should've google'd a bit more though.  I found a program called ClipSpy that seems to do what you want:

http://home.inreach.com/mdunn/code/ClipSpy/clipspy.html

(The .zip file in the "download source" link actually contains a compiled executable as well.)

I can attach screenshots if you'd like, but it's probably easiest for you to just run this yourself.  (It doesn't seem to have the ability to dump the data out in plain text format.)

WRT "ordering / prioritizing" of formats: The text/html content is listed before the CF_TEXT content, so maybe there is something going on there.
If this worked in 1.0.x, then the best bet in getting this issue resolved is probably for someone who can reproduce the bug to use builds at http://archive.mozilla.org/pub/firefox/nightly/ to narrow down a regression window. Comparison of 1.0.x vs 1.5 using ClipSpy would be useful as well.
I also selected the text "Can someone ... the Clipboard?" from the bugzilla-page and copied it.

These are the formats on the Clipboard in Firefox/1.0.6 Gecko/20050716.
Probably a regression from either bug 244685 or bug 250392, if you want to narrow the regression window range.
And now in Mozilla 1.5, again I selected the text "Can someone ... the Clipboard?" from the bugzilla-page and copied it.

These are the formats on the Clipboard as displayed by ClipSpy in Firefox/1.5 Gecko/20051111.

(PS this was a terminal session, btw, it should not matter but I'd want to mention it anyway)
So this is quite clearly a case of Firefox adding support for new formats, and Outlook preferring those new formats over the old ones. More of a bug in Outlook than Firefox, I'd say, but I'm not familiar with whether the API allows for prioritization by the "sending" app.
that was quick work!!!

(In reply to comment #26)
> So this is quite clearly a case of Firefox adding support for new formats, and
> Outlook preferring those new formats over the old ones. More of a bug in
> Outlook than Firefox, I'd say, but I'm not familiar with whether the API 
> allows for prioritization by the "sending" app.

Agree w/ your assessment, w/ one exception, from trying to decode Microsoft's API docs, it looks like the receiving app gets to specify priority. So "UniformResourceLocator" and/or "UniformResourceLocatorW" are probably the formats that Overlook is picking instead of the obvious plain text.

Microsoft is clearly boneheaded (this sentence could of course end here) for prioritizing URL over plaintext. However I think Mozilla has made a poor choice as well. Not for including the URL among the clipboard data, that's OK in my book. But the poor choice is to allow the data to be "cast" or read as a "UniformResourceLocator" type. The URL is metadata, and does not represent the copied text itself. I question Firefox's practice of presenting metadata as one of the possible clipboard data formats, without a clear way of indicating to applications that it is metadata and not the data itself.

This is annoying enough that I'm now considering going back to 1.0.something.
(there are no new features / bug fixes that I can think of from 1.0 -> 1.5 that are important to me)
I tried going back to 1.07. After uninstalling 1.5 and then trying to install 1.07 I found the File/Edit/View.. title bar corrupted - the words were bunched on the left and were purely Times New Roman text.
Now back to having to cut & paste into MS Word - what a pain!!!
My problem was that anything copied from Firefox 1.5 pages became an attachment to an Outlook e-mail rather than pasted text.
I then tried going back to 1.07. After uninstalling 1.5 and then installing 1.07 I found the 'File/Edit/View..' title bar corrupted - the words were bunched on the left and were purely Times New Roman text. Restarting had no effect.
Now back to having to cut & paste from 1.5 into MS Word - what a pain!!!

Data in the following clipboard formats is added to the clipboard in Firefox 1.5 and not 1.06 when you copy text from a web page. This interferes with Outlook and a few other applications.

49316 FileGroupDescriptor
49317 FileGroupDescriptorW
49315 FileContents
49326 UniformResourceLocator
49354 UniformResourceLocatorW
This can be worked around with the CopyPlainText extension by Jeremy Gillick.
http://www.roundtwo.com/product/copyplaintext

(May I also suggest the AutoCopy extension from Michael Lidman.  It integrates with CopyPlainText and eliminates the need for pressing CTRL-C) http://autocopy.mozdev.org/

Hope this helps everyone who's been frustrated by this.







(In reply to comment #32)
> This can be worked around with the CopyPlainText extension by Jeremy Gillick.
> http://www.roundtwo.com/product/copyplaintext

Appreciate the suggestion (seems like an OK workaround), but it doesn't work with Firefox 1.5, which is the version of firefox that has the issue.
(In reply to comment #33)
> (In reply to comment #32)
> > This can be worked around with the CopyPlainText extension by Jeremy Gillick.
> > http://www.roundtwo.com/product/copyplaintext
> 
> Appreciate the suggestion (seems like an OK workaround), but it doesn't work
> with Firefox 1.5, which is the version of firefox that has the issue.
> 

You need CopyPlainText 0.3.2 or higher, from http://mozmonkey.com/
(Sorry, didn't realize the roundtwo site had the older version.)
> > On the same machine, with the same configuration, 1.0.x works
> > but 1.5 doesn't?
> Same machine, same configuration. Windows 2000, Outlook 2000.
> The only change was the upgrade from Firefox 1.0.7 to 1.5. 

Same here (well, 1.0.1 to 1.5), but otherwise the same.

If you're using Outlook 2000, whatever 1.0.x did is far preferable to pasting a .URL attachment.

> Unfortunately I think
> that that opinion puts you in the minority.

In addition to the other links previously provided, there are at least 4 messages complaining about this on the newsgroups:
http://groups.google.com/group/netscape.public.beta.feedback/msg/d38947ed2be5ef3b
http://groups.google.com/group/netscape.public.beta.feedback/msg/b9338e6eb358330a
http://groups.google.com/group/netscape.public.beta.feedback/msg/77e4bc8bdb97906a
http://groups.google.com/group/netscape.public.beta.feedback/msg/4c43921298bbfcf7

> the best bet in getting this issue resolved is
> probably for someone who can reproduce the bug to use builds at
> http://archive.mozilla.org/pub/firefox/nightly/

Does this still need to be done, or has the ClipSpy stuff above narrowed it down enough already?
(In reply to comment #35)
> > the best bet in getting this issue resolved is
> > probably for someone who can reproduce the bug to use builds at
> > http://archive.mozilla.org/pub/firefox/nightly/
> 
> Does this still need to be done, or has the ClipSpy stuff above narrowed it
> down enough already?

No, getting a precise regression range would still be useful - even if it's only to find which of the bugs mentioned in comment 24 is the culprit. Testing builds around the dates those bugs were landed is probably a good idea, but it's possible this is a regression from another bug. Binary search is also useful when trying to find regression ranges.
Keywords: regression
Is this interesting in helping find out what is wrong :
Pasting text into the main text area of Outlook e-mails leads to a URL attachment but the same text CAN be pasted into the To/cc/bcc AND Subject lines.....
The text can also be pasted into a Word document and then copied and pasted into the e-mail without any problem.
> getting a precise regression range would still be useful
 
Sorry, I thought that I could help, but I can't. I've just downloaded firefox-1.0+.en-US.win32.zip from 2004-12-08-07, but when I run it, the window just sits there, and I can't get any of the menus to work at all. I've also tried the "-safe-mode" switch, but it doesn't work either (I can still see that it is loading an extension). The same thing happened with the 2004-12-23-08 build (these were the two start dates I picked for the binary search). I'm guessing that I've got some version 1.5 extensions or something installed that's stuffing it up, but I really don't want to mess around uninstalling / reinstalling / etc. If there's a simple easy test that works and won't stuff up my 1.5 install, then I'm happy to do that, but as far as I can tell there isn't :-(

> the same text CAN be pasted into the To/cc/bcc AND Subject lines..

I don't think that means anything. The To/CC/BCC areas are far more restricted in terms of the content that they can hold, whereas the body text can be quite varied (HTML, plain text with attachments, etc).
> > > This can be worked around with the CopyPlainText extension by Jeremy Gillick.
> > > http://www.roundtwo.com/product/copyplaintext
> > 
> > Appreciate the suggestion (seems like an OK workaround), but it doesn't work
> > with Firefox 1.5, which is the version of firefox that has the issue.
> > 
> 
> You need CopyPlainText 0.3.2 or higher, from http://mozmonkey.com/
> (Sorry, didn't realize the roundtwo site had the older version.)
 
I've been using this and it is a viable workaround, though still annoying as I forget about it from time to time & end up pasting a url into Outlook, then have to go back & do shift-ctrl-C.

Keyboard-mapping Q: is there an easy way to swap these two, e.g. map Ctrl-C to CopyPlainText, and map shift-Ctrl-C to the "default" behavior of Firefox to copy formatted HTML, URLs, etc. to the clipboard (which I essentially never use)?
(I looked online for a little while & couldn't find anything on firefox keyboard mapping)

(In reply to comment #38)
> If there's a simple easy test that works and won't stuff up
> my 1.5 install, then I'm happy to do that

You can create a new profile using the old build to ensure that nothing from your current profile interferes. Just run the build with the -p switch to get the profile manager, and use it to create a new profile, leaving your original profile intact.
(In reply to comment #39)
> > You need CopyPlainText 0.3.2 or higher, from http://mozmonkey.com/
> > (Sorry, didn't realize the roundtwo site had the older version.)

I don't have any problem with pasting into Outlook 2003 from FF 1.5.0.1 but was having problems pasting from FF into QuattroPro - It would paste the url of the page I was copying from instead of pasting the text. Your suggesion of CopyPlainText did the trick regarding pasting into QuattroPro. Now all I have to do is remember to right click to do the copying.
Thanks.
> You can create a new profile using the old build to ensure that nothing from
> your current profile interferes. Just run the build with the -p switch to get
> the profile manager, and use it to create a new profile, leaving your original
> profile intact.

Thank you, the -p switch allowed me to run the tests, and sorry to take so long to get back to you on this. 

My binary search results were as follows, using the builds from: http://archive.mozilla.org/pub/firefox/nightly/  -

2004-12-06-08-trunk/firefox-1.0+.en-US.win32 - no problem - pasted as normal text, so works fine. Browser build string: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041206 Firefox/1.0+
2004-12-07-08-trunk/firefox-1.0+.en-US.win32 - yes, has problem - pastes text as .URL attachment. Browser build string: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041207 Firefox/1.0+

So something checked into the build within that 24-hour window would seem to be the cause.
That points to the patch for bug 244685, which was checked into the tree on 2004-12-07 06:13.
(In reply to comment #44)
> That points to the patch for bug 244685, which was checked into the tree on
> 2004-12-07 06:13.

Indeed. Thanks for narrowing it down, Nick.
Assignee: nobody → win32
Blocks: 244685
Component: General → Widget: Win32
OS: Windows 2000 → Windows XP
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
Though I should point again to my comment 26, indicating that this might just be a bug with Outlook: see also http://groups.google.com/group/microsoft.public.outlook/browse_thread/thread/cd0f836a93d1dbc0/c267642f29465b5d%23c267642f29465b5d?sa=X&oi=groupsr&start=2&num=3 which speaks of the same behavior when copying links from IE to Outlook.
(In reply to comment #44)
> That points to the patch for bug 244685
FWIW, that was a duplicate of my bug 235986, which called for the addition of the source URL in the CF_HTML data (it was missing).  But 244685 went further, encompassing drag/drop. That's likely where the additional formats came from, enabling drag/drop.  I suspect that suppression of some of these new formats, and not the standard "HTML Format" (CF_HTML) is what is needed here.  
Yes, I expect it's the "FileContents" and "UniformResourceLocator" formats that are causing the trouble here.  Maybe 233685 could be adjusted to only involve the drag/drop formats when you're actually doing a drag/drop, and not when you're copying/pasting text.  That's probably the way most people would use it, anyway.

> Though I should point again to my comment 26, indicating that this might just
> be a bug with Outlook: see also
> http://groups.google.com/group/microsoft.public.outlook/browse_thread/
> thread/cd0f836a93d1dbc0/c267642f29465b5d%23c267642f29465b5d?sa=X&oi=groupsr&start=2&num=3
> which speaks of the same behavior when copying links from IE to Outlook.

I've just tested this, and I get the same behaviour using with IE5.01sp4 and Outlook2000 as described in that post (Using Right Click on a link then "Copy Shortcut" in IE, then pasting into Outlook, gives a .URL attachment). Note however that normal text on a web page copies fine, and a link copied normally via Ctrl-C copies OK (it copies and pastes the link label text, not the URL).

Strangely, Firefox is the exact reverse about what creates an attachment: if I copy text normally via Ctrl-C from Firefox to Outlook, I get a .URL attachment; But if I right click on a link and go "Copy link location", and then paste that into Outlook, I get the literal http:// URL text, not a .URL attachment.

If it comes down to a choice between the two behaviours, the IE approach seems the better compromise, because copying page text seems to me the far more common operation.
What is the status of this bug? It has been almost two months since the last post. Will this be fixed for 1.5.0.2?

Would it be possible to fix this along the suggestions from comment 27 - have the URL location be metadata, instead of being on the equal level as the data itself?

Now as for Outlook 2000, could there be a remote chance that Microsoft would actually fix this on their end? Outlook 2000 is still supported with security patches until 2007 I think.

On a practical level this problem continues to be incredibly annoying, more than any other problem in Firefox that I have encountered.
(In reply to comment #49)
> What is the status of this bug? It has been almost two months since the last
> post. Will this be fixed for 1.5.0.2?

Well, just tested a snapshot, it's not fixed in the snapshot and I don't think any developer is working on it.

All information users can provide had been provided.

We now need a mozilla developer to look at it and make a decision about what behaviour Mozilla should have.

Then if needed, it can be changed.

If we want Mozilla developers to get involved, we should all vote for this bug.

So please, all interested parties vote for this bug.

Hi everyone,
 so to summarize, Outlook 2000 is grabbing the UniformResourceLocator flavour from the DataObject when you copy and paste a selection from Firefox.

The reason that the UniformResourceLocator flavour was added was to enable passing the URL of the current document through to the DataObject code where it could embed it for the CF_HTML content (as mentioned in bug 244865) for copy and pasting only (when a drag and drop is done, the URL can be obtained without requiring this)

So, after reviewing the code in question (it has been quite a while since i did that patch), one solution that comes to mind is to pass through the URL as a "custom" flavour, such that it isn't going to confuse apps like Outlook 2000.

There are already two custom flavours eg. "text/_moz_htmlinfo" that are included.

The only reason we would not want to change this is if there were other applications out there that *are* making use of the UniformResourceLocator flavour in a good way.

Maybe what I could do is whip up a modified version of Firefox and get some of you Outlook 2000 users to have a play with it and see if it fixes that problem and doesn't create too many others.

-dave
I don't have Outlook 2000 so I can't test this patch completely myself, but at least it doesn't appear to break the previous functionality of Copy/Paste or Drag/Drop into OneNote.

Patch is against current trunk source. If it works ok, I'll back-port it to 1.5 if approved.

-dave
I've created a release build of the latest trunk code of Firefox that includes this patch.

You can download a copy from http://www.unisanet.unisa.edu.au/staff/davidgardiner/mozilla/

(Reminder, this is a build of trunk code eg. not the same as the 1.5 releases!)

follow these steps to test it:
1. Unzip the file somewhere
2. Open a command prompt and navigate to the "firefox" folder.
3. Close any existing instances of Firefox you may have running.
4. Run using a different profile (so it doesn't mess up your existing extensions/settings. eg. "firefox.exe -p TestingProfile"
5. Copy/paste text from browser pages into other apps (eg. Word, Notepad, Outlook)
6. Drag/drop text from browser pages into the same apps.
7. Let me know if something doesn't work properly!

-dave
Status: NEW → ASSIGNED
*** Bug 309113 has been marked as a duplicate of this bug. ***
I'd love to test, but trunk builds no longer work on Win 98SE.

But will test once it's ported to 1.5 - thanks!
> follow these steps to test it:
> 1. Unzip the file somewhere
done

> 2. Open a command prompt and navigate to the "firefox" folder.
done

> 3. Close any existing instances of Firefox you may have running.
done

> 4. Run using a different profile (so it doesn't mess up your existing
> extensions/settings. eg. "firefox.exe -p TestingProfile"
done

> 5. Copy/paste text from browser pages into other apps (eg. Word, Notepad,
> Outlook)
Copy/paste in Outlook 2000 on win2000: no problems. Copied text is pasted as plain text
Other MS applications: no problems. Tested in Word 2000, Excel 2000, Access 2000, NotePad, ans WordPad

> 6. Drag/drop text from browser pages into the same apps.
Drag and drop: no problems. Tested on the same applications. Same results.

> 7. Let me know if something doesn't work properly!
Evereything works fine as far as I can see. Tested on Windows 2000 SP2

Jay V, some other tester
Since this is core, a patch will probably will make it into SeaMonkey, but please see bug 309113 since it discusses both FF and SM. This is a regression for FF, but it's be a problem for SM for quite a while too. Thanks.
> I've created a release build of the latest trunk code of Firefox that includes
> this patch.

I've just tested with this - "Minefield" browser id is: "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060416 Firefox/3.0a1", running on Win2000 SP4.

Can copy and paste into Outlook 2000 without problems (appears as text, no attachments - yay!). This works for both "Plain text" and "HTML" formatted emails.

Notepad works as expected, Word 2000 works as expected, Excel works as expected (well apart from bug 137450, but that's an entirely separate problem), PowerPoint works as expected, and pasting back into the browser (into textboxes and the address bar) also works as expected.

So, yes, it looks like a winner to me.

> follow these steps to test it:

One small addition:
Step 8: Start your original Firefox install with a "-p" argument, then select your original profile, in order to restore it (at least, this is what I had to do).
Actually, one small thing (which I've only just noticed now that I can compare it to Firefox 1.5.0.2) is that in the test build, dragging the site icon in the address bar, into either an Outlook 2000 email or Notepad, would result in a drag and drop icon, and releasing it would do nothing. However, using Firefox 1.5.0.2, dragging the site icon into Notepad gives a "cannot drag" mouse pointer icon, and dragging and dropping into Outlook 2000 gives an attachment.

Note that I'm not sure what should happen when the site icon is dragged (it may be that new behaviour is the correct one), and it may be that this behaviour has nothing at all to do with this bug, but since it was related to drag and drop, I thought I should mention it just in case it was relevant.
(In reply to comment #53)
> I've created a release build of the latest trunk code of Firefox that includes
> this patch.
> 
> You can download a copy from
> http://www.unisanet.unisa.edu.au/staff/davidgardiner/mozilla/
> 
> (Reminder, this is a build of trunk code eg. not the same as the 1.5 releases!)
> 
> follow these steps to test it:
> 1. Unzip the file somewhere
> 2. Open a command prompt and navigate to the "firefox" folder.
> 3. Close any existing instances of Firefox you may have running.
> 4. Run using a different profile (so it doesn't mess up your existing
> extensions/settings. eg. "firefox.exe -p TestingProfile"
> 5. Copy/paste text from browser pages into other apps (eg. Word, Notepad,
> Outlook)
> 6. Drag/drop text from browser pages into the same apps.
> 7. Let me know if something doesn't work properly!
> 
> -dave
> 

I see no difference in behaviour between 1.5.0.1 and your build, concerning copy&paste and drag&drop, except for the intended change.
Assignee: win32 → David.R.Gardiner
Status: ASSIGNED → NEW
Comment on attachment 218505 [details] [diff] [review]
Don't cause UniformResourceLocator flavour to be added to clipboard dataobject (against trunk)

Patch changes the way we pass the URL flavour through the Clipboard so that it works properly with Outlook 2000 (and other applications).

-dave
Attachment #218505 - Flags: superreview?(blizzard)
Attachment #218505 - Flags: review?(roc)
blizzard isn't doing reviews, but roc can probably just r+sr.
What about comment #59? Seems to me that that's a small regression from this patch, with the site icon not being drag/dropabble into Outlook.
good point - I meant to chase that up to confirm if that was a regression or just a "feature" of the current trunk code.

I'll add an update when I know if it's my patch that is causing this.

-dave
(In reply to comment #59)
> Actually, one small thing (which I've only just noticed now that I can compare
> it to Firefox 1.5.0.2) is that in the test build, dragging the site icon in the
> address bar, into either an Outlook 2000 email or Notepad, would result in a
> drag and drop icon, and releasing it would do nothing. However, using Firefox
> 1.5.0.2, dragging the site icon into Notepad gives a "cannot drag" mouse
> pointer icon, and dragging and dropping into Outlook 2000 gives an attachment.

I've managed to get hold of Outlook 2000 and install in Virtual PC into which I also put the Minefield build. I also tested a vanilla Minefield build (eg. without this patch) and the results for dragging the site icon from the address bar were identical.

eg. Dragging to notepad did not work, and dragging to Outlook 2000 created a Url attachment.

So I'm pretty confident that this patch hasn't changed the existing behaviour.

Robert, if you can review/super review this please?

-dave
Comment on attachment 218505 [details] [diff] [review]
Don't cause UniformResourceLocator flavour to be added to clipboard dataobject (against trunk)

can you arrange checkin?
Attachment #218505 - Flags: superreview?(blizzard)
Attachment #218505 - Flags: superreview+
Attachment #218505 - Flags: review?(roc)
Attachment #218505 - Flags: review+
The patched version works for me on XP prof sp1. I mean the copy/paste (and drag and drop) to outlook 2000 is now back to what it used to be: working. (of course, since I managed to nearly trash my profile while using it, I am not going to test it further).
I don't have check-in permission - i'd be grateful if you could do it for me.

Also, do you have an opinion on whether this is likely to be accepted for 1.8.1 and/or 1.8.0.3?

thanks,
-dave
1.8.1, no problem. 1.8.0 is unlikely.
Checked in attachment 218505 [details] [diff] [review] on the trunk.
mozilla/content/base/src/nsCopySupport.cpp 	1.48
mozilla/widget/src/windows/nsDataObj.cpp 	1.76
Target Milestone: --- → mozilla1.9alpha
Does hurt to ask :-)

thanks Gavin and Robert,

-dave
Flags: blocking1.8.1?
Flags: blocking1.8.0.4?
Marking fixed since this is in on the trunk. David: you might want to ask for approval on the patches.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Possible workaround for Outlook 2000 / Firefox 1.5 users is a "paste as text" macro for Outlook. Initial code posted here: http://forums.mozillazine.org/viewtopic.php?p=2221587#2221587
By the way, I have just noticed that Thunderbird has the same problem: copy/paste some text from thunderbird to outlook does not work either.
Is this fix part of a common part of Firefox/Thunderbird or will it have to be implemented too separately in TB ?
(In reply to comment #74)
> Is this fix part of a common part of Firefox/Thunderbird or will it have to be
> implemented too separately in TB ?

The code is common, so this fix affects Thunderbird too.
Version of patch suitable for 1.8 branch
Attachment #219828 - Flags: approval-branch-1.8.1?
Attachment #219828 - Flags: approval-branch-1.8.1? → approval-branch-1.8.1?(roc)
Attachment #219828 - Flags: approval-branch-1.8.1?(roc) → approval-branch-1.8.1+
Improves compatibility between Firefox and Outlook 2000. Fixes problem with Outlook 2000 picking the wrong flavour from the clipboard in a copy/paste.
Attachment #219841 - Flags: approval1.8.0.4?
Flags: blocking1.8.0.5? → blocking1.8.0.4?
It's too late for this kind of non-critical regression fix in 1.8.0.4, it could possibly be considered for early 1.8.0.5

Get it landed and tested on the 1.8 branch in the meanwhile.
Flags: blocking1.8.0.5?
Flags: blocking1.8.0.4?
Flags: blocking1.8.0.4-
Attachment #219841 - Flags: approval1.8.0.5?
Attachment #219841 - Flags: approval1.8.0.4?
Attachment #219841 - Flags: approval1.8.0.4-
My personal feeling is that this should not land in 1.8.0.x. The problem is not very serious and the fix, while not large, is not totally trivial either.
FYI, the first half of attachment 218505 [details] [diff] [review] (comment 70) seems to have caused bug 336012. See bug 336012 comment 5.
Not blocking 1.8.0.5 per roc's comment
Depends on: 336012
Flags: blocking1.8.0.5? → blocking1.8.0.5-
See bug 336012 comment 24.

Also: the 1.8 branch patch is approved but hasn't yet landed.  Is there a reason that the 1.8 patch as attached to this bug doesn't include the nsCopySupport.cpp diff?
Hmm.. reviewing my 1.8 Branch patch, it does look like i've missed part of the patch there - partly due to the fact that that nsCopySupport code has been reorganised there.

-dave
If you do resurrect the 1.8 branch patch, please include the part 1 fix from bug 336012.
Revised patch for 1.8 Branch, that also takes into account the part 1 fix of Bug 336012

-dave
Attachment #219828 - Attachment is obsolete: true
Attachment #225418 - Flags: superreview?(roc)
Attachment #225418 - Flags: review?(roc)
Attachment #225418 - Flags: approval-branch-1.8.1?(roc)
Comment on attachment 225418 [details] [diff] [review]
Don't cause UniformResourceLocator flavour to be added to clipboard dataobject (against 1.8 Branch)

What happened to the nsCopySupport diff (again)?
Comment on attachment 225418 [details] [diff] [review]
Don't cause UniformResourceLocator flavour to be added to clipboard dataobject (against 1.8 Branch)

Good question! I'm sure I included that path on my diff, but apparently not :-(

Second try coming. Marvellous what a difference an extra slash makes.

-dave
Attachment #225418 - Attachment is obsolete: true
Attachment #225418 - Flags: superreview?(roc)
Attachment #225418 - Flags: review?(roc)
Attachment #225418 - Flags: approval-branch-1.8.1?(roc)
Patch for 1.8 branch - and this time I didn't forget the gravy :-)
Attachment #225496 - Flags: superreview?(roc)
Attachment #225496 - Flags: review?(roc)
Attachment #225496 - Flags: approval-branch-1.8.1?(roc)
Comment on attachment 225496 [details] [diff] [review]
Don't cause UniformResourceLocator flavour to be added to clipboard dataobject (against 1.8 Branch)

>-          // Add the URL DataFlavor to the transferable
>-          rv = AppendString(trans, shortcut, kURLMime);
>+            // Add the URL DataFlavor to the transferable. Don't use kURLMime, as it will
>+            // cause an unnecessary UniformResourceLocator to be added which confuses
>+            // some apps eg. Outlook 2000 - (See Bug 315370). Don't use
>+            // kURLDataMime, as it will cause a bogus 'url' flavor to

The space in there was intentional, this should be 'url '.  It's a four-byte constant.

>+            // show up on the Mac clipboard, confusing other apps, like
>+            // Terminal (see Bug 336012)
>+            rv = AppendString(trans, shortcut, kURLPrivateMime);
>           NS_ENSURE_SUCCESS(rv, rv);

What's up with the indentation?
new patch coming - i also missed a couple of other things. Remind me not to make gravy.

-dave
Attachment #225496 - Flags: superreview?(roc)
Attachment #225496 - Flags: review?(roc)
Attachment #225496 - Flags: approval-branch-1.8.1?(roc)
Does this look better Mark? 

Fixed indentation and restored ' '. 

Also we don't bother getting the page title, as this isn't required (same as trunk patch)

I'll wait a bit until I bother Robert again, just in case I've done something else silly.

-dave
Attachment #225496 - Attachment is obsolete: true
Comment on attachment 225505 [details] [diff] [review]
Don't cause UniformResourceLocator flavour to be added to clipboard dataobject (against 1.8 Branch)

OK.
Attachment #225505 - Flags: review+
Attachment #225505 - Flags: superreview?(roc)
Attachment #225505 - Flags: approval-branch-1.8.1?(roc)
Comment on attachment 219841 [details] [diff] [review]
Don't cause UniformResourceLocator flavour to be added to clipboard dataobject (against 1.8.0 Branch)

minusing for 1.8.0.5 per comment 79
Attachment #219841 - Flags: approval1.8.0.5? → approval1.8.0.5-
Attachment #225505 - Flags: superreview?(roc)
Attachment #225505 - Flags: superreview+
Attachment #225505 - Flags: approval-branch-1.8.1?(roc)
Attachment #225505 - Flags: approval-branch-1.8.1+
Flags: blocking1.8.1? → blocking1.8.1+
I don't have checkin privileges, so it would be great if someone else could check in the 1.8 (aka 1.8.1) branch patch.

-dave
Checked in on MOZILLA_1_8_BRANCH for 1.8.1b1:

content/base/src/nsCopySupport.cpp 1.44.8.2
widget/public/nsITransferable.idl 1.11.8.1
widget/src/windows/nsClipboard.cpp 1.95.2.5
widget/src/windows/nsDataObj.cpp 1.69.2.2

I needed to adjust the nsCopySupport.cpp hunk after bug 303818 landed.
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: