Closed Bug 135268 Opened 22 years ago Closed 16 years ago

Support OSX services

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
All
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: kasumi, Assigned: tom.dyas)

References

(Blocks 1 open bug)

Details

(Keywords: platform-parity)

Attachments

(1 file, 2 obsolete files)

Add support for Services menu (v2)
4.73 KB, patch
jaas
: review+
roc
: superreview+
Details | Diff | Splinter Review 
tested 2002-04-02-08-trunk
OS = Mac X(10.1) 

1. Launch Navigator
2. Select Netscape/Services... in menu bar
3. Select Disk copy/ount image is disabled
4. Select Grab/Screen, Selection, Timed screen are disabled
5. Select Mail/Mail Document, Mail text, Mail to are disabled
6. Select Make Sticky, Summarize are disabled
7. Select Text Edit/pen File, Open Selection are disabled

Expected: does function properly.
Keywords: nsbeta1
-> XP APS
Assignee: Matti → blaker
Component: Browser-General → XP Apps: GUI Features
QA Contact: imajes-qa → paw
This is an RFE.  Virtually no Carbon based app, actually I don't know of _any_,
supports the Services menu yet.
Severity: major → enhancement
IE on mac os x doesn't support this either
nsbeta1-/1.1
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.1alpha
umm. --> pink?
Assignee: blaker → pinkerton
future, over to dagley for tracking
Assignee: pinkerton → sdagley
Summary: All OSX specific functions in Netscape/Services menu don't function because they are disabled → [RFE] Support OSX services
Target Milestone: mozilla1.1alpha → Future
Dupe of Bug 104331 [Add items to Services menu on Mac OS X]?
No. Bug 104331 is about the browser *supplying* a service ("Open URL in...").
This bug is about getting the browser to support existing services (e.g. getting
selected text).
Since I don't report into Internet Technologies anymore this bug needs a new
owner -> saari
Assignee: sdagley → saari
->sfraser
Assignee: saari → sfraser
these are all working i Chimera 20021202 !-)
The backend part of this is covered by bug 196704.
Status: NEW → ASSIGNED
Depends on: 196704
*** Bug 211068 has been marked as a duplicate of this bug. ***
Support for the OS X Services menu really needs to be added. The usefulness of
Mozilla and Firebird are greatly reduced without support for the Services menu.

This should be a high-priority fix.
Blocks: 253283
Simon--what's left to do on this bug?
*** Bug 260619 has been marked as a duplicate of this bug. ***
I think we need to implement some carbon event handlers to get services support
(memory foggy).
I've been looking at this off and on.  I hacked up nsAppShell.cpp to install the
proper event handlers, and that's working fine (although I'm not sure if
nsAppShell.cpp is the right place to put this stuff).  In order to make this
work, I need to find if there is anything selected at the moment in Mozilla, and
if so, get that selection.  That's what I'm having problems with right now.
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → Event Handling
Keywords: nsbeta1- → helpwanted, pp
Product: Mozilla Application Suite → Core
Blocks: macmeta
*** Bug 273038 has been marked as a duplicate of this bug. ***
*** Bug 277457 has been marked as a duplicate of this bug. ***
*** Bug 278662 has been marked as a duplicate of this bug. ***
No longer blocks: 253283
*** Bug 253283 has been marked as a duplicate of this bug. ***
*** Bug 285338 has been marked as a duplicate of this bug. ***
*** Bug 287125 has been marked as a duplicate of this bug. ***
FYI, Apple's current documentation on Carbon apps supporting the Services menu (URL changed):

http://developer.apple.com/documentation/Carbon/Conceptual/appservices/index.html

it is possible since Camino is geckobased too like Firefox and the services
works perfectly well in it.
Assignee: sfraser_bugs → events
Status: ASSIGNED → NEW
QA Contact: pawyskoczka → ian
*** Bug 313150 has been marked as a duplicate of this bug. ***
Tested this with Camino nightly 2005102804 (v1.0a1+) running under 10.3.9.

When I select Camino -> Services -> Search with Google, Camino launches Safari, and searches Google, alright.

If this isn't going to be fixed for 1.0 (along with the other services mentioned in this bug), might a note be added in the Release Notes?
>When I select Camino -> Services -> Search with Google, Camino
>launches Safari, and searches Google, alright.
>
>If this isn't going to be fixed for 1.0 (along with the other services
>mentioned in this bug), might a note be added in the Release Notes?

I don't think this is a Camino bug: that item is being added to the Services menu by Safari. All items in the menu are provided by particular apps. I don't think this is a bug.
I would have to differ with you . . . it _is_ a bug.  Services from within Camino shouldn't launch Google in Safari; it should launch Google in Camino.
(In reply to comment #31)
> I would have to differ with you . . . it _is_ a bug.  Services from within
> Camino shouldn't launch Google in Safari; it should launch Google in Camino.

But unfortunately we have no control over this. It's one of the many issues with Services.
*** Bug 319622 has been marked as a duplicate of this bug. ***
*** Bug 330234 has been marked as a duplicate of this bug. ***
*** Bug 332165 has been marked as a duplicate of this bug. ***
*** Bug 340102 has been marked as a duplicate of this bug. ***
Just ran into this bug trying to use MacGPG to sign text in a web form. Sure would be nice to get this to work, instead of having to launch a separate signing app every time I need to sign email composed in a web form.
*** Bug 351132 has been marked as a duplicate of this bug. ***
(In reply to comment #31)
> I would have to differ with you . . . it _is_ a bug.  Services from within
> Camino shouldn't launch Google in Safari; it should launch Google in Camino.
> 

why shouldn't they? You set a default html handler in Safari, so from there on out, whichever browser is chosen as 'default', remains the default. Services are application-independent, but when they in turn need a handler, they launch the user-chosen default. No bug at all.
(In reply to comment #31)
> I would have to differ with you . . . it _is_ a bug.  Services from within
> Camino shouldn't launch Google in Safari; it should launch Google in Camino.
> 

why shouldn't they? You set a default html handler in Safari, so from there on out, whichever browser is chosen as 'default', remains the default. Services are application-independent, but when they in turn need a handler, they launch the user-chosen default. No bug at all.
(In reply to comment #27)
> it is possible since Camino is geckobased too like Firefox and the services
> works perfectly well in it.

Exactly. Why hasn't this comment been addressed as to why SeaMonkey and Firefox are so non-compliant with Apple APIs that other gecko-based browsers have no problem with?

If the decision has been made to ignore the need for a compliant fork of Firefox and SeaMonkey, devs should make the announcement so Mac users are not misled into thinking this is a Mac-friendly app. In its present incarnation it is NOT a Macintosh app. 

why not grab a volunteer from the Camino project, and get this Services situation straightened out, what would that take? 15 minutes? Come on.
the issue with the service opening Google in Safari is a bug with the service itself and out of our hands.

I'd just like to +1 this bug as Services are the means some applications use for inter-app communication. Most-recent example: OmniFocus and their clipping feature.
I created bug 408459 (above), not realizing that this one already existed (like so many before me it appears).  I did dutifully search before making the dupe, although I did not notice this bug.

It seems like an odd bug to have been plaguing the project for so long, I assumed it was new with Leopard.  I'm a little shocked I hadn't noticed it before.  Has this been seen affecting any other applications under OS X? I imagine not many with as high a visibility as Firefox.

I've tried selecting text in a dozen odd applications, some are pretty dodgy small freeware tools, and they all seem to manage it okay.

Quicksilver is also not able to use its 'Current Selection' proxy object on text selected in Firefox, which I imagine is related.  An eclectic example to be sure.

This issue is probably not a make/or break feature for many, but it is pretty disheartening.


This is un-doable in Carbon apps, like Firefox. You'll need to wait for a Cocoa app or use Camino; this bug should probably be resolved WONTFIX since the Mac port won't be redone in Cocoa any time soon from what I know of the roadmap.
Greg,

That's absolutely untrue. Carbon apps are totally capable of putting items into the services menu, and items in the services menu can access carbon apps.

One notable example is BBEdit.
Re: Services unavailable in Carbon apps:

ADC begs to differ:

"Introduction to Setting Up Your Carbon Application to Use the Services Menu"

http://developer.apple.com/documentation/Carbon/Conceptual/appservices/intro/chapter_1_section_1.html

Nominating for 1.9 to get it considered for wanted-next ...
Flags: blocking1.9?
Might want to add "ue" to the keywords' list.
OK.  Wanted next.
Flags: wanted-next+
Flags: blocking1.9?
Flags: blocking1.9-
3.0 is released and still no services support... yikes.

Carbon apps can support services - we do in our product Mariner Write and have for years. We are (currently) a carbon app. 

We'd (Mariner Software) be willing to donate the code (carbon services code) to get this working as we have many users with Firefox and MacJournal, MacGourmet, etc.. that would LOVE to be able to use the Services menu in Firefox. This bug has a ton of fluff up above mainly boiling down to three things:

a) trying to define what "Services are" - I think that is well enough defined.
b) trying to decide whether carbon apps can support them (they can, Mariner Write does BBEdit does,etc..)
c) Talking about how Camino supports services (related to b above)
I would love Services so I could use LaunchBar with Firefox.  This would be fabulous to utilize the Mac's Dicitonary app and sending the text to other apps.
http://www.obdev.at/products/launchbar/index.html
Somehow this keeps getting left by the wayside - I see it isn't in the planned list for Firefox 3.1.  I'm surprised that even with Corey/Mariner's offer to contribute the code this seems to be stalled.  I code, but I haven't even looked at the Firefox/Mozilla code to see how this would be integrated.  If it would help get this done sooner and someone who is familiar with the code would point me in the right direction I'd offer to assist.
I'm seconding Jon's comments.  I'm a 12 year C++/C/Java developer and would help contribute effort if given some pointers on integrating Mariner's code.  I desperately want this integration.  Without it, I'm relegated to a lot of my mac apps just relying on bookmarklets (which aren't selection-aware, frequently) for apps like DevonThink capture of FF web page text.  We seem to have everything in line to get this in 3.1...

1) Code donation 2) Effort volunteers and all we need is 3) Someone from FF with core knowledge to help us out getting started in the right direction...

Please help us help the community.
Attached patch Add support for Services menu (obsolete) — — Splinter Review 
This patch implements the Cocoa methods necessary to allow items on the Services menu to communicate with Firefox.  It only supports copying text.

Nit: validRequestorForSendType:returnType: is called many times as part of Mac OS figuring out which items on the Services menu should be disabled or enabled.  We might need to cache the selection somehow if this method ends up slowing things down by calling into Gecko each time to obtain the selection.
Attachment #349014 - Flags: review?(joshmoz)
Anyone want to test a version of Firefox with this patch for me?
Sure. I'll test.  Is there a location to grab a binary? Let me know.  Matthew McCullough, matthewm@ambientideas.com
I'll email you the location in a moment.
send me the locale too - and I'll take it for a spin.
The patch also works for two others (comment #60 and comment #61) who tested it.  I just changed the contributor line in this version of the patch.
Attachment #349014 - Attachment is obsolete: true
Attachment #350871 - Flags: review?(joshmoz)
Attachment #349014 - Flags: review?(joshmoz)
Just tried this patch in a fresh clone of 1.9.1, and it resolves the most important issue of enabling the services menu when selecting text, as advertised in comment #58.  Even with ~40 items in my service menu, the pause when opening the Services menu (due to OS X calling validRequestorForSendType once for each item in the menu) is barely noticable.

So while I confirm that this patch does work for me and that it is a wonderful step forward that many of us have clearly been waiting for for a long time, I also note that resolution of this issue based on this patch would suggest the creation of a follow-up enhancement issue to add handling of selected images.

I certainly hope this patch can make it into 3.1
Comment on attachment 350871 [details] [diff] [review]
Add support for Services menu (v1.1)

+- (id)validRequestorForSendType:(NSString *)sendType
+                     returnType:(NSString *)returnType

It isn't really clear to me how we're supposed to deal with nil "sendType" and/or nil "returnType". Please document that or rearrange the logic to make it more clear.

+    if ( (!sendType || hasSelection) && (!returnType) )

Please don't put spaces after/before "(" and ")" in an "if" condition. This happens in more than one place in the patch, including above this line.

+    if ( (!sendType || hasSelection) && (!returnType) )

Let's trust that the reader knows the basics of operator precedence and not put parenthesis around "!returnType". We don't do that anywhere else in the file afaik.

+  return [super validRequestorForSendType:sendType
+                returnType:returnType];

Put that one one line or at least align the ":" characters.

Thanks for doing this!
(In reply to comment #65)
> (From update of attachment 350871 [details] [diff] [review])
> +- (id)validRequestorForSendType:(NSString *)sendType
> +                     returnType:(NSString *)returnType
> 
> It isn't really clear to me how we're supposed to deal with nil "sendType"
> and/or nil "returnType". Please document that or rearrange the logic to make it
> more clear.

sendType is nil when the service does not want the application to send any information, i.e. writeSelectionToPasteboard:types: will not be called.  (It might be a service that only produces information, in which case returnType != nil.)  returnType is similar is nil when the service will not be sending back any information.

> +    if ( (!sendType || hasSelection) && (!returnType) )
> 
> Please don't put spaces after/before "(" and ")" in an "if" condition. This
> happens in more than one place in the patch, including above this line.
> 
> +    if ( (!sendType || hasSelection) && (!returnType) )
> 
> Let's trust that the reader knows the basics of operator precedence and not put
> parenthesis around "!returnType". We don't do that anywhere else in the file
> afaik.

Both were in the sample code from Apple docs.  Will fix.
Cleaned up patch as per Josh's comments including adding comments.  Added class initialized for ClassView in order to call registerServicesMenuSendTypes:returnTypes: on NSApplication as per Apple's documentation for using system services.  Services still work with the modified patch.
Attachment #350871 - Attachment is obsolete: true
Attachment #351094 - Flags: review?(joshmoz)
Attachment #350871 - Flags: review?(joshmoz)
s/ClassView/ChildView/
Attachment #351094 - Flags: review?(joshmoz) → review+
Who should handle superreview?
Attachment #351094 - Flags: superreview?(roc)
Attachment #351094 - Flags: superreview?(roc) → superreview+
Any chance of getting this landed on the trunk?
Assignee: events → tdyas
Keywords: helpwanted → checkin-needed
QA Contact: ian → events
Summary: [RFE] Support OSX services → Support OSX services
Target Milestone: Future → ---
landed on trunk

http://hg.mozilla.org/mozilla-central/rev/923d927753ce
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
We should get this on the 1.9.1 branch too, assuming the patch works there.
I'm not sure I agree, I think we need to start cutting down on the number of patches we send to 1.9.1 that are not stability and security fixes. This is a new feature. There is more work to be done on services and it has very little testing at this point.
(In reply to comment #73)
> I'm not sure I agree, I think we need to start cutting down on the number of
> patches we send to 1.9.1 that are not stability and security fixes. This is a
> new feature. There is more work to be done on services and it has very little
> testing at this point.

Agreed.  No need to land on 1.9.1 branch as it's a new feature.
> Platform: PowerPC Mac OS X

No mention of Intel here. 

Please: can we confirm whether this resolution is effective for users of Mac OS X on Intel?

(If so, maybe change the 'Platform' of this ticket?)
> more work to be done on services

Please, can we refer to tickets that relate to the more work on System Services? 

I would like to cast my votes. 

Already found: 
https://bugzilla.mozilla.org/show_bug.cgi?id=104331 
https://bugzilla.mozilla.org/show_bug.cgi?id=367867 
and possibly https://bugzilla.mozilla.org/show_bug.cgi?id=394599 

Many thanks.
I don't know about the others who tested the patch, but I tested on OS X Intel and it worked fine.

Note that the bugs mentioned in comment #76 divide into two issues - (1) those seeking the ability to use services provided by other applications on content selected in FF and (2) those desiring that FF (and other Moz apps) offer services of its own.  Those are very different issues with completely different use cases, even though they both relate to the Services menu, and this bug is very clearly pertaining only to the first of those issues.

And because I haven't said it before: Thanks to everyone who got this issue resolved.
Hardware: PowerPC → All
> Product: Core

> Platform:	All Mac OS X

> two issues - (1) … use services provided by other applications on
> content selected in FF … this bug is very clearly pertaining only to
> the first of those issues.

@ Jon

Many thanks for clarifying, so re 
http://developer.apple.com/documentation/Cocoa/Conceptual/SysServices/Concepts/architecture.html#//apple_ref/doc/uid/20000850-BCIDHJJA 
the recent landing on trunk should lead to: 

* the Mozilla product becoming a _service provider_. 

Two minor questions, for one or both I expect to be referred to the URL for an FAQ (forgive me; I'm familiar with Trac for Plone and fairly familiar with Bugzilla and EIS for OOo, but _very_ new to Bugzilla@Mozilla):

1. Focusing on this one issue 135268: beyond Firefox, which other Mozilla products should benefit from the December landing?

(Sunbird, and Thunderbird with Lightning, are of greatest interest to me.)

2. For landings in general: where do I look to see the processes/estimated timeline for progressions from trunk, to release?

In any case, for my intentions it *is* this issue 135268 
(currently RESOLVED FIXED) that is of greatest relevance. 

@ all

Definitely, thanks for contributions and for the recent breakthrough!
Blocks: 470642
> Please, can we refer to tickets that relate to the 
> more work on System Services? 
> 
> I would like to cast my votes. 

https://bugzilla.mozilla.org/show_bug.cgi?id=470642 is my request for enhancement relating to loss of hyperlinks etc., loss which occurs as the string is flowed from provider service in Firefox to processor service in an application such as Stickies.
(In reply to comment #64)

> resolution of this issue based on this patch would suggest the
> creation of a follow-up enhancement issue to add handling of
> selected images.

New bug 470651 (request for enhancement) relates to 

> provider services to support images

Specificially: 

> System Services (interapplication communication on Mac OS X): 
> provider services to support images in Mozilla applications
Verified fixed on the trunk using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20081222 Minefield/3.2a1pre as well as the equivalent nightly build on Tiger. I verified according to the notes made in Comment 58.

I also nominated for in-litmus since this will need to be added to the set of tests for the next release.
Status: RESOLVED → VERIFIED
Flags: in-litmus?
Josh, given that it's a very small patch exposed via what appears to be limited UI surface area, wouldn't it be likely to see sufficient testing between now and the time 1.9.1 ships?
Is there a reason this landed without any tests? Is this code untestable? If so, what bug does it depend on to have the test infrastructure required for automated tests?

Josh?
Flags: in-testsuite?
Automation aside: FWIW I volunteer to click test in Mac OS X 10.5.6 or greater on Intel.
This would be hard to test if at all possible. We don't control the services menu. Not worth it IMHO. Lets just go for litmus.
And sorry, I still don't think we should take this for 1.9.1. Too late for a new feature, too risky despite smallish surface area, and there is more work to do for proper support.
Josh,

I'm sure there are MANY that would love to test this feature.

1. What are the risks?
I assume them to be:
a. a crash under some circumstance
b. non-functional under some circumstance

2. can you elaborate on the "more work to do for proper support"?
There are still major problems with this feature (bug 473030 for example) making it too likely that we'd have to take patches in a dot release. We are past feature freeze and this is immature. Apparently nobody had even tested invoking services by keyboard command until around January 10, 2009.
(In reply to comment #87)
> 2. can you elaborate on the "more work to do for proper support"?

The services support doesn't post the selected HTML, only plain text, to the services pasteboard so formatting information is currently lost.  The solution is more invasive than this patch and would require lots of testing.  (The solution being to extend nsQueryContentEvent so a nsITransferable can be returned, updating contents/events/src/nsQueryContentEventHandler.cpp to handle that event by using the helper functions in the clipboard code, and then leveraging the existing clipboard code in widget/src/cocoa to post the nsITransferable to the services pasteboard.)
Blocks: 479093
Blocks: 104331
http://stackoverflow.com/a/35254053/38108

> … it seems to me that the 2008 resolution is no longer effective.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: