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)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: xn--mlform-iua, Unassigned)
References
()
Details
(Keywords: helpwanted, intl, platform-parity, Whiteboard: [p-safari][gs])
Attachments
(1 file)
60.90 KB,
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
Reporter | ||
Comment 2•24 years ago
|
||
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
Reporter | ||
Updated•24 years ago
|
Severity: normal → critical
Comment 3•24 years ago
|
||
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
Reporter | ||
Comment 4•24 years ago
|
||
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!
Reporter | ||
Comment 5•24 years ago
|
||
>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...
Comment 6•24 years ago
|
||
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
Reporter | ||
Comment 7•24 years ago
|
||
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.
Comment 9•24 years ago
|
||
> 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
Comment 11•24 years ago
|
||
--> i18n
Assignee: pinkerton → nhotta
Component: XP Toolkit/Widgets → Internationalization
QA Contact: jrgm → andreasb
Comment 12•24 years ago
|
||
IQA, please test this and comfirm if reproducible, thanks.
Comment 13•24 years ago
|
||
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)
Reporter | ||
Comment 14•24 years ago
|
||
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.
Reporter | ||
Comment 15•24 years ago
|
||
Excuse me for the typo: you are *not* testing correctly. But I get the typo was
obvious.
Comment 16•24 years ago
|
||
i thought you were complaining about intra-mozilla... let me try different apps
Comment 17•24 years ago
|
||
I just mentioned in the other bug 10816, current code depends on OS system
charset. What is your testing environment, Marina, Leif?
Comment 18•24 years ago
|
||
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
Comment 19•24 years ago
|
||
but i think that because of the system enviroment ( mine is EN not russian) it
can not be pasted corrertly into plain text.
Comment 20•24 years ago
|
||
NS6 (and 4.x) needs localized OS (not language kits), e.g. in order to copy
Japanese text, it needs Japanese localized MacOS.
Comment 21•24 years ago
|
||
yea, in my case it is an expected behavior ( en system with lang packs) , i
don't know about Leif..
Reporter | ||
Comment 22•24 years ago
|
||
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).
Comment 23•24 years ago
|
||
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.
Reporter | ||
Comment 24•24 years ago
|
||
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...
Reporter | ||
Comment 25•24 years ago
|
||
Besides, there is -- as far as I know - no localized russian version of the
MacOS since MacOS 7.5...
Comment 26•24 years ago
|
||
actually all you need is a localized version of editor (SimpleText),
Communicator pastes it correctly only into the localized simpleText
Reporter | ||
Comment 27•24 years ago
|
||
Actually, that is not true.
Reporter | ||
Comment 28•24 years ago
|
||
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!
Reporter | ||
Comment 29•24 years ago
|
||
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...
Comment 30•24 years ago
|
||
patches are welcome if you disagree with the status quo
Reporter | ||
Comment 31•24 years ago
|
||
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.)
Comment 32•24 years ago
|
||
Changing QA contact to marina@netscape.com for now.
QA Contact: andreasb → marina
Comment 33•24 years ago
|
||
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
Reporter | ||
Comment 34•24 years ago
|
||
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)
Comment 35•24 years ago
|
||
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
Comment 36•24 years ago
|
||
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.
Comment 37•24 years ago
|
||
> 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.
Comment 38•24 years ago
|
||
future
Reporter | ||
Comment 39•24 years ago
|
||
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.
Comment 40•24 years ago
|
||
Comment 41•23 years ago
|
||
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... ;)
Comment 42•23 years ago
|
||
*** Bug 101285 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•23 years ago
|
Target Milestone: Future → mozilla1.0
Comment 43•23 years ago
|
||
no touchey my target milestone.
Reporter | ||
Comment 44•23 years ago
|
||
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...
Comment 45•23 years ago
|
||
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.
Comment 46•22 years ago
|
||
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.
Comment 47•22 years ago
|
||
*** Bug 192096 has been marked as a duplicate of this bug. ***
Comment 48•22 years ago
|
||
Shouldn't we move this to Mac OS X ? But then it becomes a dupe of bug 178523, I
think. See also bug 186550.
Comment 49•22 years ago
|
||
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.
Comment 50•22 years ago
|
||
*** Bug 178523 has been marked as a duplicate of this bug. ***
Comment 51•22 years ago
|
||
*** Bug 175110 has been marked as a duplicate of this bug. ***
Comment 52•21 years ago
|
||
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".
Reporter | ||
Comment 53•21 years ago
|
||
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
Comment 54•20 years ago
|
||
*** Bug 279331 has been marked as a duplicate of this bug. ***
Comment 55•20 years ago
|
||
*** Bug 283731 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Summary: Mac style text 'styl' support for mozilla clipboard → Mac style text 'styl' or RTF support for mozilla clipboard
Comment 56•20 years ago
|
||
*** Bug 287129 has been marked as a duplicate of this bug. ***
Comment 57•20 years ago
|
||
*** Bug 287131 has been marked as a duplicate of this bug. ***
Comment 58•19 years ago
|
||
*** Bug 180625 has been marked as a duplicate of this bug. ***
Comment 59•19 years ago
|
||
*** Bug 334601 has been marked as a duplicate of this bug. ***
*** Bug 343377 has been marked as a duplicate of this bug. ***
Comment 61•18 years ago
|
||
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.
Comment 62•18 years ago
|
||
Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before commenting in bugs.
Comment 63•18 years ago
|
||
(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.
Comment 64•18 years ago
|
||
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
Whiteboard: [p-safari]
Depends on: 428096
Comment 68•17 years ago
|
||
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?)
Reporter | ||
Comment 69•17 years ago
|
||
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.
Comment 70•17 years ago
|
||
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?
Comment 71•17 years ago
|
||
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.
Comment 72•17 years ago
|
||
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-
Comment 73•16 years ago
|
||
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.
Comment 74•16 years ago
|
||
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 |
Comment 75•16 years ago
|
||
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
Comment 76•16 years ago
|
||
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).
Comment 77•16 years ago
|
||
This bug affects TinyMCE, FCKEditor and any javascript based rich-text editor embedded in the firefox browser.
Comment 78•14 years ago
|
||
Steven, is this something that you're interested in working on?
Comment 79•14 years ago
|
||
> 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.
Comment 80•14 years ago
|
||
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.
Comment 81•14 years ago
|
||
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.
Comment 82•14 years ago
|
||
> 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.
Comment 83•14 years ago
|
||
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)
Comment 84•9 years ago
|
||
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.
Comment 85•9 years ago
|
||
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.
Description
•