Closed Bug 79864 Opened 24 years ago Closed 9 years ago

Mac style text 'styl' or RTF support for mozilla clipboard copy/paste

Categories

(Core :: Widget: Cocoa, enhancement)

Product:
Core
Component:
Widget: Cocoa
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: xn--mlform-iua, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, intl, platform-parity, Whiteboard: [p-safari][gs])

Attachments

(1 file)

screenshot of styled text copied from Mozilla
(deleted), image/png
Details 
If one try copy for excample cyrillic text (se sample URL above) inside the
browser, the editor/composer or the mailer, only the characters that also belong
to the ASCII character set will be copied. The rest is simply ignored. (So you
end up with pasting just commas, periods, spaces etc.) I call this *critical*,
because it prevents cooperation with other applications. It is also impossible
to copy non-MacRoman (e.g. cyrillic) from external programs and paste it into
Composer or Mailer. Instead of cyrillic it will be pasted in as western euorpean
letters (iso-8859-1). This bug has also been reported to the Localization part
of bugzilla, but since the template there lacked an appropriate category, I also
report it here.
from http://bugzilla.mozilla.org/bug_status.html#severity
Critical: crashes, loss of data, severe memory leak.

Sorry.
Assignee: asa → trudelle
Severity: critical → normal
Component: Browser-General → XP Toolkit/Widgets
QA Contact: doronr → jrgm
Whiteboard: DUPEME
THank you for quoting. "Loss of data". Isn't loosing all the text you copy
considered "loss of data"? Imagine that you copy text in english and all that is
copied/pasted being the space and perids. I suppose you would call it data loss.

Not sorry
Severity: normal → critical
This could involve data loss scenarios if the original source text has scrolled
or refreshed away; and is at least Major severity (loss of major function).  The
description mentions two problems, with both intra-app and inter-app copy/paste,
which may be distinct. Copying within the app should be unicode throughout
though, so let's start with editor, cc pinkerton.
Assignee: trudelle → beppe
Component: XP Toolkit/Widgets → Editor
QA Contact: jrgm → sujay
Thank you for supporting me in that this is serious on the Mac. This is a long
overdue bug. Which I for different reasons did not get myself to report properly
earlier. However, I don't think I said that the bug is inter-app. That seems to
work. What I meant is that one cannot bring text via the clipboard into Mozilla
or out of Mozilla if the text is non-8859-1. (I have only tested with cyrilic.)
THe only workaround is saving to files and importing files/html pages. TO be
"Normal" there should be and *easy* workaround!
>intra-app and inter-app
Sorry for confusing -- it is not *intra-app* (intra-mozilla), but it is
inter-app. And good night, for now...

if it's inter-app only, it's probably a dupe of one i have, or have once had on 
mac. the i18n team might have it now.
Assignee: beppe → nhotta
Component: Editor → Internationalization
QA Contact: sujay → andreasb
See <http://bugzilla.mozilla.org/show_bug.cgi?id=10816> "Add unicode clipboard
support on the Mac". It was submitted 1999, but nothing has been done since 30
th of march 2000....! This very critical bug is not even mentioned among the
"known issues" in the Mozilla milestone release notes. See also
<http://bugzilla.mozilla.org/show_bug.cgi?id=78039>, about japanese/unicode,
clipboard and FIzilla.

NOne of those reports have the appropriate Severity rating though.

In the defence for my own report I will say: I report this a general issue (it
is not only related to unicode encodings -- although techically it might be
since all Mozilla text is unicode internally. I make it clear that this bug
relates to all non-MacROman text!! (And also to mac-roman text if unicode
encodings is used on the text to copy.) My report is also not about Fizilla, but
about the regular version.

And speaking about I18N team: the bug template for Localization is also supposed
to be used for "bugs with languages other than english", ie L10N and I18N issues
is mixed together. However, the template only contains Categories for L1=N issues.
*** Bug 79861 has been marked as a duplicate of this bug. ***
> And speaking about I18N team: the bug template for
> Localization is also supposed
> to be used for "bugs with languages other than english",
> ie L10N and I18N issues
> is mixed together.

No, it says "Also for reporting browser bugs in languages other than english."
You can reports bugs in Russian, and someone who speaks Russian can translate
it, and add it as "real" bug.
Assignee: nhotta → trudelle
Component: Internationalization → XP Toolkit/Widgets
QA Contact: andreasb → jrgm
->Pink for triage
Assignee: trudelle → pinkerton
--> i18n
Assignee: pinkerton → nhotta
Component: XP Toolkit/Widgets → Internationalization
QA Contact: jrgm → andreasb
IQA, please test this and comfirm if reproducible, thanks.

using 2001-04-30 build (Leif,what build did you use?) i am not able to reproduce
the problem; here are the steps:
-go to the above URL;
- change encoding for the first paragraph to KOI8-R;
- highlight the text, copy, paste into Composer or Mail composition window;
result: all copied text is pasted correctly, no omissions
(Mac OS 9.0)
Hi -- Marina, I use Build ID 2001051005 at the moment. 

As far as I can see you are doing the same thing as I. To test the bug I have
reported, you must copy text from the above URL and paste it *not* into Composer
or Mail (that is *not* inter-Mozilla), but instead you have to paste the text
into SimpleText, WorldText (if you have OS9.1) or whichever external editor you
might have. YOu should also try the reverse: paste cyrillic text *from*
SimpleTExt to Mozilla Mail or Editor. It is not possible.

Excuse me for the typo: you are *not* testing correctly. But I get the typo was
obvious.
i thought you were complaining about intra-mozilla... let me try different apps
I just mentioned in the other bug 10816, current code depends on OS system
charset. What is your testing environment, Marina, Leif?

OK, as for inter-applications pasting i can confirm the bug, using SimpleTExt or
Office for Mac the cyrillic text is not pasted, all that is in a clipboard are
commas and dashes. I am using English system, Mac OS 9.0 with language packs
but i think that because of the system enviroment ( mine is EN not russian) it
can not be pasted corrertly into plain text.
NS6 (and 4.x) needs localized OS (not language kits), e.g. in order to copy
Japanese text, it needs Japanese localized MacOS.

yea, in my case it is an expected behavior ( en system with lang packs) , i
don't know about Leif..
Marina -- please make sure you also try to test pasting text *from* an external
app and into Mozilla. 

I am using Norwegian MacOS 9.1, Cyrillic Language Kit as well as Central
European Language kit. I have just tested a polish web site <URL
http://www.gazeta.pl >, and the result is similar: when pasting text from that
page into WorldText the accented polish letters are dissolved. Eg. a letter
looking like Z but with a comma at the bottom (I don't know polish alphabet,
sorry) is pasted as two letters: a Z + a comma. I suspect similar result for all
language kits. I could do some testing with greek and hebrew also, if you wish.
Though I will not do it today, I need to install the language kits. At least to
test hebrew (greek is not language kit based).


i guess what you're seeing is expected: text editor is system dependent: e.g. if
you have western system it won't work with central europeen languages. for that
behavior to be a bug we have to have russian system and try cyrillic text
copy/paste.
I am 100% sure you guess is wrong. I use NisusWriter as my editor. Just like
SimpleText, WorldTExt, WordPerfect 3.5 for Mac, Ready,Set,GO GLobal, Magellan
puh - the list is too long - no one of these programs require russian MacOS. Or
polish for that matter.

At the NIsusWriter mailing list we have made a lot of jokes about MS Office
products however, which seems to work perhaps the same way you describe. But
that is limitations designed to get users to suppor Japanese MacOS or something.
IE for mac and iCab does not require localized OS. Only requirement is Cyrillic
Language kit. And the same can, btw, be said about Netscape Communicator 4.x. 

If you conclusion becomes the end of this story then am of course not goingn to
use Mozilla anymore... PS: I will ask a polish programmist to take a look at
this page. He is and expert on multilingualism on the Mac, which I am not sure
that you are...
Besides, there is -- as far as I know - no localized russian version of the
MacOS since MacOS 7.5...
actually all you need is a localized version of editor (SimpleText),
Communicator pastes it correctly only into the localized simpleText
Actually, that is not true.
This bug report has taken a direction that I did not expect. You -- Marina --
has verified my finding. But you hesitate to confirm it as a bug, because you
have doubts or other expectations (to low expectations) about the behaviour. Or
to little experience with cyrillic (and polish) on the mac. As a experineced
user of cyrillic on the Mac I of course know that what I say am right in my
expectations. And I have nothing more until we get to discuss the reall issue
here. I am also surprise by  nhotta's remark that "NS6 (and 4.x) needs localized
OS (not language kits), e.g. in order to copy Japanese text". I have neverd
heard *that* from the many japanese netscape for mac users at the Nisus list
among whom there are both US and Japanese OS users. And at least it is not true
that Netscape 4.X and MacCyrillic need anything more special than LanguageKit!


To elaborata on the Netscape 4.X behaviour: I don't think it copies any language
information at all [when it comes to cyrillic]. Only the ascii text. Meaning
that to paste cyrillic text from 4.X you need to either paste inside a string of
text in a cyrillic font. Or you must change the keyboard layout (from the "flag
menu") to a cyrillic keyboard before you paste. Also, in 4.X for the Mac,
unicode is not possible to paste. If you copy text from a UTF-8-encoded page, it
will be pasted into the editor (even the Mail editor of 4.X) as UTF-"entities",
i.e. as "code". I was especially looking for improvement of these things when I
started to test Mozilla many months ago. And it appeared to me that copying
unicode text worked back then a few times. It must have been pre-Netscape 6.0.
But it doesn't any more. (My memory might play me a trick, perhaps it never worked.)

I would expect something better than that from Mozilla. And at least I would
expect *improvements* as opposed to the current status, where the method
described for 4.X is not possible.  -- Good night...
patches are welcome if you disagree with the status quo

Thank you, but I only work in the bug finding business. (And that is a hard
business, judging from how hard it is to get you accept this bug.)
Changing QA contact to marina@netscape.com for now.
QA Contact: andreasb → marina
I was wrong about 4.x. I tried with Japanese text on 9.1 with a lang pack, it
works. In 4.x, it just passing around text data without conversion, so it works
as long as the charset matches with the other app's expected charset.

I think other app's supports for charset is mostly done by styled text 'styl'. I
commented about this in bug 10816.

I also put a patch to bug 10816, that is for plain text copy for unicode text
'utxt'.

We can keep this bug for 'styl' support or dup as a 'utxt' support. Or is this
requesting for the same behavior as 4.x?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think you are right in that other app's supports for charset is mostly done by
styled text 'styl'. Unfortunately I can't build anything so I need a prebuild
thing to test with..

I suggest keeping this bug for 'styl' support and not dup as a 'utxt' support. I
would prefer suppor for both things. And *not* 4.x behaviour, please!

Please also have a look at the technical notes I posted in the bug report about
utxt clipboard support from my polish programmist friend Thomas. (Bug 10816)

Plain text issue to be addressed by bug 10816, change it to 'styl' support which 
also supports multiple scripts copy/paste, and reassign to xptoolkit.
Assignee: nhotta → trudelle
Severity: critical → enhancement
Component: Internationalization → XP Toolkit/Widgets
Keywords: intl
Summary: non-8859-1 can not be transported via clipboard to other Applications → Mac style text 'styl' support for mozilla clipboard
Whiteboard: DUPEME
Yes, Leif, you are right. I confirm this bug is reprodued with Japanese text 
too.

I just tried Mozilla 0.9 US (MacOS 9.1 English with JLK) and was astonished to 
find that I cannot copy and paste Japanese text from Mozilla to another 
application like Simple Text. All the characters which are not low ascii have 
been removed!?!

What is more astonishing is that I read here a comment by someone in Netscape: 
"NS6 (and 4.x) needs localized OS (not language kits), e.g. in order to copy 
Japanese text, it needs Japanese localized MacOS." ??? You have never used 
NS4? With NS 4.x, I can always copy and paste a text regardless of script. 
Note that I'm not satisfied with this behavior, because NS 4.x is the only 
application which supports multi languages and does NOT support copy and paste 
with style, i.e. with script instruction. I have to re-apply fonts according 
to the original script.

And Netscape people should know that all the WorldScript savvy applications 
including Unicode editors like Sue and World Text do work fine regardless of 
OS's nationality.

> by someone in Netscape: "NS6 (and 4.x) needs localized OS (not language kits)
That's me, I somehow misunderstood about 4.x behavior (see my comment on 
2001-05-11 10:17), sorry about that.
Anyway, let's stop putting things not really related to the bug, that's not 
constructive, bugs getting unreadable.

>All the characters which are not low ascii have been removed!?!
I think this is a bug. Characters which fails unicode conversion are fallback to 
'?'. I guess that's not what really wanted by the user, though. Anyway, please 
file a bug separately and discuss in there.

>WorldScript savvy applications including Unicode editors like Sue and World 
>Text do work fine regardless of OS's nationality.
I think that's related to mozilla's cross platform approach and having own 
widget. Not easy to take advantage of OS native support or other components 
(e.g. WASTE). If any enhancement requests, please file bugs separately, thanks.



future
Assignee: trudelle → pinkerton
Keywords: helpwanted
Target Milestone: --- → Future
How does Bug 24010 "text/plain from an external app is restricted to ISO-8859-1" relate to this bug? Remember that I from the beginning reported *two* things: unability to paste *from* Mozilla. And "conversion" of all non-MacRoman text into letters from ISO-8859-1 when pasting from external app *into* Mozilla. Hopefully 'utxt' clipboards from external applications will be pasted correctly when 'utxt' support is turned on in Mozilla. (Currently also such clipboards becoms ISO-8859-1). But until 'styl' is supported, how can one paste in e.g. MacCyrillic text unless it also carries the 'utxt' format ? In other words: lack of 'styl' support = Bug 24010.
I put a comment to bug 24010, that bug is fixed. Remaining "text/plain"
clipboard issue to be addressed in bug 10816, or to be filed separately as
request for enhancement.

Is this now fixed, then? I can't seem to reproduce it at the moment, but I seem to be 
"special" sometimes... Theoretically, copying from the URL listed at the top of the bug 
using IE, pasting into the scrapbook and then pasting to Mozilla should all show the 
same results if all is working correctly? I have been looking at this bug this way, at 
least... ;)
*** Bug 101285 has been marked as a duplicate of this bug. ***
Target Milestone: Future → mozilla1.0
no touchey my target milestone.
Status: NEW → ASSIGNED
Keywords: mozilla1.0
Target Milestone: mozilla1.0 → Future
This is also a policiy debate. Se Bug 108029 for a suggion of a better solution
of the unicode on the clipboard problem. It is a very simple solution, because
like I said it is only a policy decision... 
Build: 2002-03-15-6.2.2
OS: MacOS 10.1 JA

Copy DBCS characters(in this case Japanese) to .txt, .rtf successfully.
Vice versa has no problem also.  
Kasumi: copying between Unicode-aware apps (like most cocoa apps on OS X) will
work, because they transfer unicode. 'styl' support is required for non-unicode
apps, on OS 9, and some carbonized apps on OS X.
*** Bug 192096 has been marked as a duplicate of this bug. ***
Shouldn't we move this to Mac OS X ? But then it becomes a dupe of bug 178523, I
think. See also bug 186550.
Actually, I think this bug should be Resolved in some fashion (dunno if it
should be Fixed, WFM, or Wontfix). Mozilla Mach-O puts styled text on the
clipboard and preserves international characters, which was the major concern
in this bug.

Bug 178523 is concerned with loss of text formatting (e.g. font
family/size/style/color/etc) compared to other Mac browsers which copy rich
text. That will probably end up Wontfix.

Bug 186550 is about FAULTY styles on the clipboard, causing the desired plain
text to instead paste as a bizarre non-desired font.

There must be a dependency relation between all 3, but the direction is
unclear.
*** Bug 178523 has been marked as a duplicate of this bug. ***
*** Bug 175110 has been marked as a duplicate of this bug. ***
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".
This bug is also an issue in Mac OSX. The most important problem which the
fixing of this bug would have solved in Mac OS Classic would have been that it
had made it possible to work with multilingual texts in those applications that
do not support the unicode clipboard.

But styl support have advantages even in OSX. Without styl support it is
impossible to paste formatted (or "styled") text from MOzilla and into for
instance TextEdit.

Hence I mark this as an OSX bug.
OS: Mac System 8.5 → MacOS X
*** Bug 279331 has been marked as a duplicate of this bug. ***
*** Bug 283731 has been marked as a duplicate of this bug. ***
Summary: Mac style text 'styl' support for mozilla clipboard → Mac style text 'styl' or RTF support for mozilla clipboard
*** Bug 287129 has been marked as a duplicate of this bug. ***
*** Bug 287131 has been marked as a duplicate of this bug. ***
*** Bug 180625 has been marked as a duplicate of this bug. ***
*** Bug 334601 has been marked as a duplicate of this bug. ***
*** Bug 343377 has been marked as a duplicate of this bug. ***
As Leif Halvard Silli   2003-09-08 04:52:05 PST Comment #53 states back in 2003, this is a bug across all Gecko-based browsers. I am running Mac OS X v10.4.8 on a 2.1 GHz PowerPC G5 iMac, and can reproduce the inability to copy styled/formatted text in Firefox 2.0.0.1, Camino 1.0.3, and SeaMonkey 1.5a. I have conversed with Camino development and received this reply:

From:   stridey@gmail.com
Subject: Re: Clipboard support
Date: January 13, 2007 12:18:51 AM EST
To:   owndao@aol.com

Ah, yes.  That's a Core (Gecko) bug, and isn't really fixable on Camino's end. Unfortunately nobody there seems to care very much.  Here's hoping. ;)

Cheers, Stridey

On Jan 13, 2007, at 12:11 AM, Joe E. Hodge, III wrote:

Thanks for the fast response. By clipboard support like Safari I mean retaining the styles/format of the text not just copying to the clipboard a plain text version. In Safari you can cut stylized text with tables, etc and paste that into you word processor. I do this type thing very often in taking notes from online sources by copy/paste rather than trying to keep up by re-typing and re-formatting, etc. Safari does it, IE used to do it, but Camino and Firefox do not seem to sadly.

Joe E. Hodge, III, BEE
Systems Integration Engineer
owndao@aol.com
2305 Husson Ave, Apt. i62
Palatka, Fl 32177
Cell Phone: 386-538-1932
VoIP: 352-482-0369



On Jan 13, 2007, at 12:00 AM, stridey@gmail.com wrote:

Camino has cut and paste.  See the Edit menu, or Cmd-C, Cmd-V.  Camino 1.1a2 has the ability to spellcheck using the OS X dictionary, and we're working on the dictionary popup.  The Firefox team is totally separate, so you should mention that to them too if you want them to know. :)

Cheers, Stridey

On Jan 12, 2007, at 10:00 PM, Joe E. Hodge, III wrote:

Needs clipboard support as in Safari for cut/paste. Also, use of OS X dictionary for spell checking, etc. Firefox needs this too.


Joe E. Hodge, III, BEE
Systems Integration Engineer
owndao@aol.com
2305 Husson Ave, Apt. i62
Palatka, Fl 32177
Cell Phone: 386-538-1932
VoIP: 352-482-0369



=

=

=

=


Well I can assure you that any Mac user that uses this browser to copy/paste research notes finds this a CRITICAL problem. Safari can do it and it is a fundamental part of the entire Macintosh phylosophy of applications integration that it must work. I am bitterly disappointed in the cavalier attitude this continuing bug has been addressed with. Please tell me this fix is in the works for release soon.
Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before commenting in bugs.
(In reply to comment #61)
> Well I can assure you that any Mac user that uses this browser to copy/paste
> research notes finds this a CRITICAL problem. Safari can do it and it is a

This assertion is patently untrue. Were it even the least bit truthful, this bug would have been fixed by now. There's a reason it has a severity of "enhancement" and a "helpwanted" tag on it.

Furthermore, as Stuart so appropriately pointed out, you seem to be unable to follow basic instructions for commenting in bugs. Please read and commit to memory

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

before commenting on Bugzilla again.

Thank you.

Please disregard Chris's comment; it was completely out of line.

The fact that it's a parity issue that is important to some users is definitely understood, but it's a non-trivial amount of work and resources are limited.
Assignee: mikepinkerton → joshmoz
Status: ASSIGNED → NEW
Component: XP Toolkit/Widgets → Widget: Cocoa
QA Contact: marina → cocoa
Assignee: joshmoz → nobody
Comment 46 states that 'styl' support is useful only on OS 9 or OS X with Carbon. Is this relevant now that we've switched to cairo-cocoa and have a full release out using that? (and even removed widget/mac from the tree) (I'm a little fuzzy on the relationship between Carbon and Cocoa but I think we might still be using Carbon a little bit)

It looks like RTF support for the clipboard is still useful as bug 428096 comment 7 mentions many apps on OS X already support RTF but not HTML for the clipboard.
(hmmm, are 'styl' and RTF are synonymous?)
The original problem that I reported, was that non-ASCII text was lost when one copy from Mozilla and paste into the document of a third app. This is not an issue anymore — today this can be done without any loss of characters. 

Pasting plain text from another app into Mozilla is also not any problem anymore.

I tend to agree with Comment #49, and would say the bug should be closed.

'styl' was a feature of Mac OS 9. Via 'styl' one could support Unicode.
I agree with what you say Leif. However, the fact that Firefox does not allow for copying of any kind of formatting from a page's html/css to any other Mac application has not gone away in the 7 years that this bug has been running. If this issue is not to be addressed here then another bug should be opened and backdated to at least 2003. Frankly, if the attitude at Mozilla is reflected in the juvenile flame by 
Comment #63 [reply] Chris Lawson  2007-03-10 22:20:41 PDT, then this issue will never be resolved and Firefox will remain my second choice browser for my everyday use.<br /> The Gecko defect that is pointed out so clearly in Comment #61 ("Ah, yes.  That's a Core (Gecko) bug, and isn't really fixable on Camino's end. Unfortunately nobody there seems to care very much.  Here's hoping. ;)") by Camino development is apparently taking the Lawson "There's a reason it has a severity of "enhancement" and a "helpwanted" tag on it." rating by Firefox development. It seems that having cut and paste only supporting *plain* text (in whatever language) is the best that Firefox will ever be able to manage on OS X.
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Flags: blocking1.9.0.2?
Flags: blocking1.9.0.1?
Flags: blocking1.8.1.17?
Bug 428096 is also about this issue, and seems to be making some progress. I regularly use Firefox and Thunderbird, and I recently switched to a Mac. I was amazed that Mozilla has allowed such a major bug to remain for so long, especially with all the better Mac support that Firefox 3 was touted to bring.
This won't block any maintenance release (1.8.1.x or 1.9.0.x).
Flags: blocking1.9.0.2?
Flags: blocking1.9.0.1?
Flags: blocking1.8.1.17?
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P3
Flags: wanted1.9.1+ → wanted-next+
If you haven't voted for the duplicate of this bug (bug #428096), please do so.

https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=428096#vote_428096

I am hoping to raise the attention and importance of this issue and hopefully get the HTML, styl, rtf, img function of the Firefox clipboard finally fixed.

Thanks for helping.
Might we change this bug 79864
from Platform: PowerPC Mac OS X
from Platform: All Mac OS X?

I note that 180625 (at one time marked as a duplicate of this 79864) is re-opened. 

See also bug 470642,

----------------------------------------------------------------------------
           Summary|System Services             |Send rich text to Mac OS X
                  |(interapplication           |Services
                  |communication on Mac OS X): |
                  |provider services to        |
                  |support richer text in      |
                  |Mozilla applications        |
For the record, FCKEditor resolved a bug in their Paste from Word feature to wontfix/can'tfix because of this bug:

http://dev.fckeditor.net/ticket/711
This bug is still very relevant, in that e.g. styled copy/paste from TextEdit to Firefox is impossible.  My understanding is that this is because Firefox will read HTML from the clipboard but not RTF.

"Platform" should be set to All Mac.

This negatively affects my company's EtherPad product by making it impossible to let Mac users paste in styled text (unless of course the other app puts HTML on the pasteboard).
This bug affects TinyMCE, FCKEditor and any javascript based rich-text editor embedded in the firefox browser.
Steven, is this something that you're interested in working on?
> Steven, is this something that you're interested in working on?

I don't know much about how the clipboard works on OS X ... though of
course I could learn.  And I have a lot of other thing on my plate
(particularly related to the immanent release of OS X 10.7).

So though I'll probably get to this eventually (because it does seem
important), I'd be happy for someone else to work on it.

Are you interested?

I'm cc-ing Tom Dyas, who might also be interested (and has recently
done work that seems related, in his patch for bug 525389).

I can review your patches or Tom's.
Thanks, I'm not personally interested myself, but this came up on irc today, and the bug was about Mac, which made me automatically think of you.  :-)

But I do hope that Tom is interested.
Unfortunately, I don't have the time to work on this. I had taken a look in late 2009 and determined that the solution is to implement a way to convert from the DOM tree to RTF. The code would probably be similar to the HTML and plain text serializers for the DOM. Examples are objects implementing nsIDocumentEncoder and/or nsIFormatConverter. My only interaction with those APIs was indirectly through the code in content/base/src/nsCopySupport.cpp when I was working on the Services menu support.
> I had taken a look in late 2009 and determined that the solution is
> to implement a way to convert from the DOM tree to RTF. The code
> would probably be similar to the HTML and plain text serializers for
> the DOM. Examples are objects implementing nsIDocumentEncoder and/or
> nsIFormatConverter.

This sounds like a lot of work.

Apparently we used to have some kind of support for parsing RTF code,
which was badly broken and removed years ago (see bug 78458).  I'm not
sure how relevant this is, though, since for this bug we apparently
need to generate RTF code, not to parse it.

Finally, fixing this bug is a lot less urgent since bug 428096 was
fixed -- it's no longer true that copying formatted text never works
on the Mac.  In fact, I suspect it'd be difficult to find cases where
we really need to serialize the DOM to RTF (where serializing it to
HTML won't already be good enough).

So I'm going to keep this on my list of interesting bugs, but I'm
unlikely to get to it anytime soon.
still an issue for some people in Thunderbird - http://getsatisfaction.com/mozilla_messaging/tags/bug_79864

per a colleague "I think Apple's Mail.app gained this kind of feature
maybe, oh, I'd guess 3-4 years ago?"

(http://www.friends-partners.org/partners/rusmac/test.html seems to be AWOL)
Blocks: 78458
URL: http://www.friends-partners.org/partn... → http://getsatisfaction.com/mozilla_me...
Keywords: pp
Priority: P3 → --
Summary: Mac style text 'styl' or RTF support for mozilla clipboard → Mac style text 'styl' or RTF support for mozilla clipboard copy/paste
Whiteboard: [p-safari] → [p-safari][gs]
Target Milestone: Future → ---
There is a RTF decoder in TB:
http://mxr.mozilla.org/comm-central/source/mailnews/import/outlook/src/rtfDecoder.cpp
No idea how useful or relevant this is. Looking at bug 78458, I don't know how popular it would be to reintroduce handling of RTF.
I tested all of the encodings at http://www.dimka.com/ru/cyrillic/ and they copy successfully.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: