User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-gb) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20081220 Minefield/3.2a1pre https://bugzilla.mozilla.org/show_bug.cgi?id=135268 (currently resolved fixed but not verified) introduces a provider service. http://hg.mozilla.org/mozilla-central/rev/923d927753ce#l1.42 outlines the limitation of that particular resolution: > only support sending strings to services More specifically: the user may select hyperlinks and other non-plain text, but the result of flowing to an application that provides a processor service is: * LOSS of hyperlinks and other richness. To resolve this loss, I guess that we need, in Firefox, an enhanced or additional, provider service: * to preserve _at least_ hyperlinks * to preserve other richness of text. Reproducible: Didn't try Steps to Reproduce: 1. open firefox-3.2a1pre.en-US.mac.dmg (a nightly build) 2. from within the disk image, without copying, launch Minefield 3. visit http://www.mozilla.org/projects/firefox/ 4. select the first few paragraphs from 'Mozilla Firefox Project' to 'Developer Links', which include hyperlinks 5. Minefield menu | Services | Make New Sticky Note Actual Results: Mozilla Firefox Project Current Release Firefox 3 (June 17, 2008) Archived Releases Prior versions of Firefox Project Links Firefox 3.1 - "Shiretoko" Planning Center. The Firefox 1.0 Charter outlines the reasons behind this project, and its goals. Developer Links Expected Results: Beyond the text alone (confirmed by a Finder view of Clipboard) a provider service should have preserved the hyper-links and and other richness within the flow to the processor service in Stickies 6.0 (6.0.0). System Services-related developments at http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&p=48358#48358 and at http://qa.openoffice.org/issues/show_bug.cgi?id=94394 may be of interest.

Steps 1 through 5 were repeated, the issue is reproduced. I am adding a dependency on (resolved) bug 135268 so that readers there can note this (request for enhancement) bug 470642.

See also: bug 470651 relating to > provider services to support images

Stickies may not be the best application with which to interact. I tend to use Tofu http://amarsagoo.info/tofu/ Using Tofu in lieu of Stickies for steps 1 through 5 above: * the bug is reproduced. = Comparison = Use Safari and Tofu in lieu of Firefox and Tofu: no bug; hyperlinks and richness of text are preserved.

I'm preserving the lines below within the text of this ticket, so that the ticket can be found by searching for key words/expressions. (The new summary line is fine, thanks Smokey.) Smokey Ardisson (no bugmail - do not email) changed: What |Removed |Added ---------------------------------------------------------------------------- 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 |

Gavin: if related bug 135268 was Component: Event Handling, then why is this bug 470642 Widget: Cocoa? (I'd like to learn.) All: see also bug 180625 > Text captured through Services Menu should retain formatting

= See also = bug 470384 > copy / paste from HTML table to excel is broken

= See also = 2001 core bug 79864 > Mac style text 'styl' or RTF support for mozilla clipboard

Graham, please stop spamming any vaguely similarly-sounding bugs (especially closed ones) with mentions of this bug (and vice versa); it makes you appear to be an advocacy troll ;-) and creates excess bugmail that everyone has to wade through instead of working on fixing bugs. In most cases developers and QA are already aware of the relationships that are relevant. (In reply to comment #5) > Gavin: if related bug 135268 was Component: Event Handling, then why is this > bug 470642 Widget: Cocoa? (I'd like to learn.) Because bug 135268 was misfiled; it should have been in Widget:Cocoa. Thanks!

Smokey, I'm neither spamming nor trolling, I'm sorry you see it that way. I am cross-referencing and (amongst other things) aiming to de-duplicate. I'm taking the time to read bugs and I'm sorry that making pertinent comments generates e-mail. Where a relationship is *not* expressed within a bug, but similarities with another bug are apparent, it's impossible for the reader to *guess* whether anyone is aware of the possible relationship. I'm showing consideration for new readers of a bug, who may not be developers. > bug 135268 was misfiled; it should have been in Widget:Cocoa. It's the 'Cocoa' tag that puzzles me. I read that Cocoa is not a requirement for Mozilla to work with System Services; that it can be done with Carbon. I also read that the Cocoa port won't be done any time soon, from which I assume that Carbon may be a preferable starting point.

Graham, Smokey is right here. There is no need to comment in a bug to say "see bug x". If there is a dependency on a bug that needs to be expressed, please use the "Depends on" and "Blocks" fields. (In reply to comment #9) > It's the 'Cocoa' tag that puzzles me. I read that Cocoa is not a requirement > for Mozilla to work with System Services; that it can be done with Carbon. It can, but the work that will take place will happen in the Core::Widget:Cocoa component since that's the applicable component in Mozilla-land. And it will likely take place in Cocoa, not in Carbon since most code is being future-proofed for 64-bit.

Additionally, the "interop" keyword is for "Interoperability bugs (ie. with various IMAP mail servers)" and is specifically a mailnews keyword and is not appropriate for this bug.

(In reply to comment #11) Thank you both. New bug 471952 recognises that > description of keyword 'interop' should be more explicit and I have removed that keyword from the one other ticket where it was inappropriate. > take place in Cocoa, not in Carbon Cocoa for future proofing is perfect sense. >> bug 135268 was misfiled; it should have been in Widget:Cocoa. Does that mean that 135268 did actually take place in Cocoa, or that it *should* have taken place in Cocoa? Just one other (minor) question which I can ask off-ticket, then all will be clearer. Apologies again for the noise.

FYI, bug 479093 contains a patch that posts HTML to the services pasteboard and may resolve this bug once it lands.

The patch in bug 479093 landed on the trunk. The services pasteboard is now set to the equivalent of doing Edit->Copy, which means the rich text support is as good as it will get.

(In reply to comment #14) > … equivalent of doing Edit->Copy, which means the rich text support is > as good as it will get. Thanks. If bug 79864 is resolved, then will there be a corresponding improvement to the services experience?