Closed Bug 79864 Opened 22 years ago Closed 7 years ago
Mac style text 'styl' or RTF support for mozilla clipboard copy/paste
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
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
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
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 firstname.lastname@example.org 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
Summary: non-8859-1 can not be transported via clipboard to other Applications → Mac style text 'styl' support for mozilla clipboard
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.
Assignee: trudelle → pinkerton
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.
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. ***
no touchey my target milestone.
Status: NEW → ASSIGNED
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 188.8.131.52, Camino 1.0.3, and SeaMonkey 1.5a. I have conversed with Camino development and received this reply: From: email@example.com Subject: Re: Clipboard support Date: January 13, 2007 12:18:51 AM EST To: firstname.lastname@example.org 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 email@example.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, firstname.lastname@example.org 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 email@example.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
Depends on: 428096
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.
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).
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).
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)
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: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.