The default bug view has changed. See this FAQ.

Status

()

Core
Event Handling
--
enhancement
VERIFIED FIXED
15 years ago
a year ago

People

(Reporter: Kasumi, Assigned: Tom Dyas)

Tracking

(Blocks: 2 bugs, {pp})

Trunk
All
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9 -
in-testsuite ?
in-litmus ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

15 years ago
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.
(Reporter)

Updated

15 years ago
Keywords: nsbeta1
-> XP APS 
Assignee: Matti → blaker
Component: Browser-General → XP Apps: GUI Features
QA Contact: imajes-qa → paw

Comment 2

15 years ago
This is an RFE.  Virtually no Carbon based app, actually I don't know of _any_,
supports the Services menu yet.
Severity: major → enhancement

Comment 3

15 years ago
IE on mac os x doesn't support this either

Comment 4

15 years ago
nsbeta1-/1.1
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.1alpha

Comment 5

15 years ago
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
Some docs:
http://developer.apple.com/techpubs/macosx/Carbon/HumanInterfaceToolbox/MenuManager/appservices/index.html
Dupe of Bug 104331 [Add items to Services menu on Mac OS X]?

Comment 9

15 years ago
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).

Comment 10

15 years ago
Since I don't report into Internet Technologies anymore this bug needs a new
owner -> saari
Assignee: sdagley → saari

Comment 11

15 years ago
->sfraser
Assignee: saari → sfraser

Comment 12

14 years ago
these are all working i Chimera 20021202 !-)

Comment 13

14 years ago
The backend part of this is covered by bug 196704.
Status: NEW → ASSIGNED
Depends on: 196704

Comment 14

14 years ago
*** Bug 211068 has been marked as a duplicate of this bug. ***

Comment 15

13 years ago
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.

Updated

13 years ago
Blocks: 253283

Comment 16

13 years ago
Simon--what's left to do on this bug?

Comment 17

13 years ago
*** Bug 260619 has been marked as a duplicate of this bug. ***

Comment 18

13 years ago
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

Updated

13 years ago
Blocks: 237584

Comment 20

13 years ago
*** Bug 273038 has been marked as a duplicate of this bug. ***
*** Bug 277457 has been marked as a duplicate of this bug. ***

Comment 22

12 years ago
*** Bug 278662 has been marked as a duplicate of this bug. ***

Updated

12 years ago
No longer blocks: 253283

Comment 23

12 years ago
*** Bug 253283 has been marked as a duplicate of this bug. ***
*** Bug 285338 has been marked as a duplicate of this bug. ***

Comment 25

12 years ago
*** Bug 287125 has been marked as a duplicate of this bug. ***

Comment 26

12 years ago
FYI, Apple's current documentation on Carbon apps supporting the Services menu (URL changed):

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

Comment 27

12 years ago
it is possible since Camino is geckobased too like Firefox and the services
works perfectly well in it.

Updated

12 years ago
Assignee: sfraser_bugs → events
Status: ASSIGNED → NEW
QA Contact: pawyskoczka → ian
*** Bug 313150 has been marked as a duplicate of this bug. ***

Comment 29

12 years ago
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?

Comment 30

12 years ago
>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.

Comment 31

12 years ago
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.

Comment 32

12 years ago
(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.

Comment 33

12 years ago
*** Bug 319622 has been marked as a duplicate of this bug. ***

Comment 34

11 years ago
*** Bug 330234 has been marked as a duplicate of this bug. ***

Comment 35

11 years ago
*** Bug 332165 has been marked as a duplicate of this bug. ***

Comment 36

11 years ago
*** Bug 340102 has been marked as a duplicate of this bug. ***

Comment 37

11 years ago
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. ***

Comment 39

10 years ago
(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.

Comment 40

10 years ago
(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.

Comment 41

10 years ago
(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.

Updated

10 years ago
Duplicate of this bug: 404274
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.

Updated

9 years ago
Duplicate of this bug: 406805

Updated

9 years ago
Duplicate of this bug: 408459

Comment 46

9 years ago
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.

Comment 47

9 years ago
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.

Comment 48

9 years ago
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.

Comment 49

9 years ago
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
Duplicate of this bug: 425482
Nominating for 1.9 to get it considered for wanted-next ...
Flags: blocking1.9?

Comment 52

9 years ago
Might want to add "ue" to the keywords' list.
OK.  Wanted next.
Flags: wanted-next+
Flags: blocking1.9?
Flags: blocking1.9-

Comment 54

9 years ago
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)

Comment 55

9 years ago
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

Comment 56

9 years ago
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.

Comment 57

9 years ago
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.
(Assignee)

Comment 58

9 years ago
Created attachment 349014 [details] [diff] [review]
Add support for Services menu

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)
(Assignee)

Comment 59

8 years ago
Anyone want to test a version of Firefox with this patch for me?

Comment 60

8 years ago
Sure. I'll test.  Is there a location to grab a binary? Let me know.  Matthew McCullough, matthewm@ambientideas.com
(Assignee)

Comment 61

8 years ago
I'll email you the location in a moment.

Comment 62

8 years ago
send me the locale too - and I'll take it for a spin.
(Assignee)

Comment 63

8 years ago
Created attachment 350871 [details] [diff] [review]
Add support for Services menu (v1.1)

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)

Comment 64

8 years ago
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 65

8 years ago
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!
(Assignee)

Comment 66

8 years ago
(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.
(Assignee)

Comment 67

8 years ago
Created attachment 351094 [details] [diff] [review]
Add support for Services menu (v2)

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)
(Assignee)

Comment 68

8 years ago
s/ClassView/ChildView/

Updated

8 years ago
Attachment #351094 - Flags: review?(joshmoz) → review+
(Assignee)

Comment 69

8 years ago
Who should handle superreview?

Updated

8 years ago
Attachment #351094 - Flags: superreview?(roc)
Attachment #351094 - Flags: superreview?(roc) → superreview+
(Assignee)

Comment 70

8 years ago
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 → ---

Comment 71

8 years ago
landed on trunk

http://hg.mozilla.org/mozilla-central/rev/923d927753ce
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
We should get this on the 1.9.1 branch too, assuming the patch works there.

Comment 73

8 years ago
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.
(Assignee)

Comment 74

8 years ago
(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.

Comment 75

8 years ago
> 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?)

Comment 76

8 years ago
> 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.

Comment 77

8 years ago
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

Comment 78

8 years ago
> 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!

Updated

8 years ago
Blocks: 470642

Comment 79

8 years ago
> 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.

Comment 80

8 years ago
(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?

Comment 84

8 years ago
Automation aside: FWIW I volunteer to click test in Mac OS X 10.5.6 or greater on Intel.

Comment 85

8 years ago
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.

Comment 86

8 years ago
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.

Comment 87

8 years ago
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"?

Comment 88

8 years ago
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.
(Assignee)

Comment 89

8 years ago
(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.)

Updated

8 years ago
Blocks: 479093
Blocks: 104331

Comment 90

a year ago
http://stackoverflow.com/a/35254053/38108

> … it seems to me that the 2008 resolution is no longer effective.
You need to log in before you can comment on or make changes to this bug.