104331 - Add items to Services menu on Mac OS X

Status: RESOLVED WORKSFORME

(Firefox :: General, enhancement, P3)

Description

[Mike Akers]

It is my understanding that with OSX 10.1, carbon apps can make use of the
services menu the application menu. Mozilla should have an "Open URL" item in
the services menu atleast, like Omniweb does. Menu items for mailing selected
text would be cool too.

Comment 1

[Greg K.]

Confirming as an RFE to explore ways to utilize OS X's "Services" menu.

Comment 2

[Asa Dotzler [:asa]]

->xpapps

Comment 3

[sairuh (rarely reading bugmail)]

pink, would this belong to you?

Comment 4

[Mike Pinkerton (not reading bugmail)]

mike 'osx dumping ground' pinkerton, at your service ;)

accepting for future.

Comment 5

[Doug Grinbergs]

References:

http://developer.apple.com/techpubs/macosx/Carbon/HumanInterfaceToolbox/MenuManager/appservices/concepts/Items_in_th_rvices_Menu.html

http://developer.apple.com/techpubs/macosx/Carbon/HumanInterfaceToolbox/MenuManager/appservices/index.html

Comment 6

[sairuh (rarely reading bugmail)]

nominating for buffy.

Comment 7

[Steve Dagley]

Adding sfraser to cc: list as he's doing some related work in Chimera

Comment 8

[Rafael Ebron (:rebron)]

adt: nsbeta1-

Comment 9

[Judson Valeski]

seemingly related: http://bugzilla.mozilla.org/show_bug.cgi?id=260619

Comment 10

[HJ]

This appears to be identical to bug 135268. Although this one was filed first, that one has much more discussion and appears to be active as of June 2006. Can someone with sufficient authority verify this and mark it as a dupe if appropriate?

Comment 11

[HJ]

Crud -- ignore my previous comment. Just noticed that comment #9 in bug 135268 explains that these two are in fact different. Really should drink more coffee before posting bug reports. Sorry.

Comment 12

[Tom Dyas]

Attachment: Add items to Services menu (for discussion purposes)

This patch adds a menu item to the Services menu called "Firefox/Open URL."  When the item is selected, any text selected in the running application is selected and passed to Firefox to be opened.

The open question is:  What menu items should be supported?  It is easy enough to add additional ones just by modifying browser/app/macbuild/Contents/Info.plist.in.

Comment 13

[Tom Dyas]

Attachment: Force update of Services menu

Mac OS X only updates the items on the Services menu during the log-on sequence. So upon adding/deleting services, you must either log-out and the log-on again or just use the attached program to force an update for all applications subsequently started.  The one line compile command is in the file's comments.

Comment 14

[Tom Dyas]

Attachment: Add "Open URL" to Services menu (for discussion purposes)

The service provider code has been moved to browser/components/macservices and is registered through a new nsIMacServicesProviderService.idl.  This is so the toolkit code does not contain browser-specific code.

From a UI perspective, we need to decide what items should appear on the Services menu for the browser.

Who is the appropriate UI person?

Comment 15

[Tom Dyas]

Attachment: Add "Open URL" items to Services menu

Add "Open URL" and "Open URL in New Window" items to the Services menu for Firefox.  Need advice on localization, specifically: How should localizations of ServicesMenu.strings.in be created?  It is necessary to use this file since Mac OS X looks in that file for localizations of the menu items even when Firefox is not running.

Comment 16

[Alex Bishop]

(In reply to comment #14)
> From a UI perspective, we need to decide what items should appear on the
> Services menu for the browser.
> 
> Who is the appropriate UI person?

Try Alex Faaborg?

(In reply to comment #15)
> Need advice on localization, specifically: How should localizations
> of ServicesMenu.strings.in be created?

Axel Hecht (Pike) coordinates Mozilla localisations; hopefully he can point you in the right direction.

Comment 17

[Axel Hecht [:Pike]]

I'd suggest using an .inc file to be used by PreProcessor.py.

I'd be curious to see a screen shot of what the services menu looks like with this patch.

Comment 18

[Alex Faaborg [:faaborg] (Firefox UX)]

Yep, I'm the right person, adding uiwanted as a note to myself to come back to this bug and provide feedback on what services should be available.

Comment 19

[Tom Dyas]

Attachment: Screenshot of Minefield's "Services" Menu

Here is the requested screenshot of the "Services" menu with the items from the patch showing.

Comment 20

[Tom Dyas]

(In reply to comment #17)
> I'd suggest using an .inc file to be used by PreProcessor.py.

I'm not that familiar with that part of the build system.  Where would the .inc file be placed?

Some background on why the localized menu item strings have to be in the ServicesMenu.strings file:  Firefox's entries on the Services menu will be in place even when the browser is not running.  Mac OS X is hardcoded to look in ServicesMenu.strings for the localized version of the menu items.  There would need to be a version of this file for each locale.

> I'd be curious to see a screen shot of what the services menu looks like with
> this patch.

Posted.  While Minefield is the active application, the Services menu items for Minefield would work with whatever application is active.  (The result being that you could ask Minefield to open a URL by selecting it in any other application.)

Comment 21

[Graham Perrin]

Bug 367867 (reported 2007) may be a duplicate of this bug 104331 (reported in 2001). 

I have referred readers of 367867 to 104331 with an invitation to transfer votes to here (if duplication is confirmed).

Elsewhere, http://qa.openoffice.org/issues/show_bug.cgi?id=94394 confirmed by
OpenOffice.org QA and they 

> should really do this. 

http://developer.apple.com/documentation/Cocoa/Conceptual/SysServices/SysServices.html
- developer documentation, presumably superseding the URLs posted in 2002 (comment 5). 

Regards
Graham

Comment 22

[Tom Dyas]

(In reply to comment #21)
> Bug 367867 (reported 2007) may be a duplicate of this bug 104331 (reported in
> 2001).

Bug 367867 is more a duplicate of bug 135268, which is concerned with Firefox playing nice with other system services.  This bug deals with adding a "Firefox" menu to the Services menu.

> http://developer.apple.com/documentation/Cocoa/Conceptual/SysServices/SysServices.html

I am aware of that documentation.  Both the patch in 135268 (which has already landed on the trunk) and the patch in this bug make use of that documentation.

Comment 23

[Graham Perrin]

@ Tom

Thanks for the reassurance and pointers. Much appreciated. It's a long time since I visited Bugzilla@Mozilla, I suspect that with the few tickets that I have visited this afternoon I now have enough points to begin gaining an overview of Firefox support for System Services.

Comment 24

[Graham Perrin]

So re 
http://developer.apple.com/documentation/Cocoa/Conceptual/SysServices/Concepts/architecture.html#//apple_ref/doc/uid/20000850-BCIDHJJA this bug 104331 relates to 

* the Mozilla product becoming a _service processor_. 

> Product: SeaMonkey

Focusing on 104331: beyond Seamonkey, which other Mozilla products should benefit?

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

(I do see Firefox within the discussion, but for newcomers to this bug it should be good to understand its scope.)

TIA
Graham

Comment 25

[Alex Bishop]

Attachment: My 'Services' menu

My 'Services' menu has lots of entries like this:

Open URL
Open URL in Camino
Open URL in Opera
Open URL in RealPlayer

It seems that the convention is to have 'Open URL in [Application Name]' as a top-level item in the 'Services' menu rather than in a submenu. Opera adds both a top-level 'Open URL in Opera' item and an 'Opera' submenu (containing a single 'Send To' item).

Comment 26

[Graham Perrin]

Attachment: observing breadcrumb trails within menus

Subject: breadcrumb trails within menus

@ Alex

Thanks. Thought-provoking.

@ All

I see two approaches.

Defocusing from the fact that Opera is a browser: focus on all available applications. 

The most common approach, which appears conventional, is to use sub-menus in the normal way. One menu leads to another. 

An less common approach, is to present breadcrumb trails. 

My first reactions to breadcrumb trails were: 

1. accessibility (keyboard-based navigation)

2. clutter (the combination of two crumbs of a particular length can make the Services collection as a whole unnecessarily broad, possibly confusing to newcomers to this aspect of Mac OS X.

Educating myself, I find that the crumbs (and sometimes surprising width) occur only when an application provides no more than one single processor service. The trail is properly accessible. I guess that the trail effect (combining two menu steps into a single step) is an accessibility gem polished by Apple.

I'll attach my first screen shot before proceeding with other comments.

Comment 27

[Graham Perrin]

Attachment: focusing on the waste of vertical menu space caused by multiple menu items for a single action to multiple applications

Subject: excessive height (excessive number of Service-oriented items within a menu)

I puzzle over a very few applications breaking from conventions.

At least one application heightens the collection of menu items unnecessarily, undesirably, by offering itself twice. By coincidence one such application is Opera but we should not be swayed by the fact that Opera is a browser. 

Defocus from browsers, concentrate on:

* interface guidelines
* processor and provider services in their entirety. 

I have no comment on the precedent offered by Camino. Other applications may offer their own precents. Again we should not be swayed by the fact that Camino is a browser. Focus on the two points above.

Comment 28

[Graham Perrin]

Attachment: Open URL in

Subject: if all applications waste space in this way, then where do people draw the line?

I have a strong sense that the behaviour of Opera is definitely wrong. It should either:

a) present what appear to be its two service processors as two items that are sub to a single Opera menu

or 

b) present its 'URL opening' service processor with a single unified 'Open URL in' menu, one that should comprise Camino, Safari, OmniWeb, Opera and other installed System Services-enabled browsers.

On the subject of this comment: 

> if all applications waste space in this way, then 
> where do people draw the line?

Two aspects to that question. 

1. What if all developers of applications for Mac OS X decide to allow or create two or more top level entries for the Services menu. How enormous will that menu become? Where should developers draw the line?

2. Faced with an increasingly long collection of top-level menu items, where will end users draw the line? 

Consider (with respect) the seven year period during which users and developers of Firefox have been anticipating System Services-related improvements. Now consider all the other developers of Carbon and other applications who may have been waiting to see how other, more well resourced, groups of developers arrive at solutions. 

Now look seven years ahead and wonder how many other developers may have said "Opera and Firefox used menu space in this way. Why shouldn't we?" 

The menu of Services may become ridiculously long if developers tend to waste space ;) in which case users' answer to question (2) may be to develop a horror of the Services menu, in which case our efforts will have been wasted.

Comment 29

[Mike Akers]

Amazing that this bug is still going strong 7 years after I reported it.

Changed platform to Mac OS X All since this presumably isn't limited to PowerPC Macs.

Comment 30

[Graham Perrin]

Attachment: preferring an application-oriented single top level menu item + multiple subs approach to multiple commands

Subject: user familiarity with names of applications, versus user uncertainty and poor recollection of names of menu commands

1. In my case (YMMV) I usually know the name of the _application_ that I wish to process something.

2. Users often can not immediately recall the _name of the menu command_ that is associated with what they wish to achive.

http://markmail.org/search/?q=%22%5Bux-discuss%5D+Suggestion%3A+text+search+facility+for+menu+items%22 is a very long thread in which I noted (and occasionally contributed to) discussion of mixed offerings, mixed meanings and mixed understandings of menu commands. 

http://markmail.org/search/?q=%22%5Bux-discuss%5D+Suggestion%3A+text+search+facility+for+menu+items%22+synonym is a more refined view of discussion 

All things considered I strongly suggest a single top-level item to the Services menu: 

Firefox

with at least one item that is sub:

Open URL

----

In the screen shot attached, focusing on the presentation of processor services: 

* Sunrise has done it right. (Do not be detracted by the feature set of UI of Sunrise; this bug 104331 is focused on System Services.)

Comment 31

[Graham Perrin]

(In reply to comment #29)

> Changed platform to Mac OS X All

>> Product: SeaMonkey

Should that be changed, from SeaMonkey to Core?

Bug 135268 is Core. 

Considerations: 

* System Services processor services are desirable in Mozilla browsers other than Firefox

* I shouldn't wish a change (to Core) to in any way retard progress/development.

> Amazing that this bug is still going strong 7 years after I reported it.

Good to see recent progress, on both the process services and provider services sides of things :)

Beyond Mozilla: http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&p=48358&sid=1a03ef1a45b0efbe601bd22e7b55c4b0#48358 is a quiet but IMHO significant announcement concerning NeoOffice support for System Services. I expect that parallel/tandem expertise will be brought to OOo camp and that interested communities may learn from each other.

Comment 32

[Graham Perrin]

> I strongly suggest a single top-level item to the
> Services menu: 
> 
> Firefox
> 
> with at least one item that is sub:
> 
> Open URL

> Considerations: 
> 
> * System Services processor services are desirable in 
> Mozilla browsers other than Firefox

Refined suggestions: 

* all processor services of Firefox should be sub to the Firefox menu 
* all processor services of Flock should be sub to the Firefox menu 
* all processor services of SeaMonkey should be sub to the SeaMonkey menu

So for example 

Services >   Firefox > Open URL
                       Search
               Flock > Open URL
                       Search
          SeamMonkey > Open URL
                       Search

Comment 33

[Graham Perrin]

> * all processor services of Flock should be sub to the Firefox menu 

Spot the deliberate mistake. Sorry!

Comment 34

[Graham Perrin]

Attachment: maybe half of one level of my Services menu

> suggest a single top-level item to the Services menu: 

> {Name of application}

a) Multiply the height of the attached screen shot x2. 

b) Average, maybe three processor services beyond each of the triangles. 

c) Multiply the sum of (a) by the sum of processor services beyond the triangles. 

Ouch. Reinforces the value of sub-menus.

… and that, I'm relieved to say, is maybe the end of my flurry of activity!

Comment 35

[Josh Aas]

Comment on attachment 352982 [details] [diff] [review]
Add "Open URL" items to Services menu

+// XXX How do I obtain nsAdoptingCString without defining this macro?
+#define MOZILLA_INTERNAL_API

Don't define this and don't use nsAdoptingCString. You don't need it.

+      urlAsCString = [urlAsCocoaString UTF8String];
+      if (!CheckURL(urlAsCString))
+	urlAsCString = NULL;

Fix indentation here.

Please fix that stuff and get the patch applying again. I will review faster next time :) Thanks.

Comment 36

[Tom Dyas]

Will post the latest version of my patch to the with your comments.  (I take a different approach to initializing the services support such that toolkit code is not modified.)

One open issue that I need answered:  When Firefox is not running, Mac OS X is going to look into the ServicesMenu.strings file in the bundle for translations of the services menu item.  What do I need to do to make sure that Mozilla translators pick this file up and create local translations?

Comment 37

[Tom Dyas]

Also, I need UI input:  Should the only services menu item supported by Firefox be a "Open in Firefox" item?

Comment 38

[Josh Aas]

(In reply to comment #37)
> Also, I need UI input:  Should the only services menu item supported by Firefox
> be a "Open in Firefox" item?

I don't know the answer to that unfortunately. I was going to look into it in the next review.

Comment 39

[Josh Aas]

Sorry, that last comment is confusing because we commented at the same time. I meant to reply to comment #36.

(In reply to comment #36)
> One open issue that I need answered:  When Firefox is not running, Mac OS X is
> going to look into the ServicesMenu.strings file in the bundle for translations
> of the services menu item.  What do I need to do to make sure that Mozilla
> translators pick this file up and create local translations?

I don't know the answer to that unfortunately. I was going to look into it in the next review.

(In reply to comment #37)
> Also, I need UI input:  Should the only services menu item supported by Firefox
> be a "Open in Firefox" item?

Probably best to just start a submenu, the menu itself called "Firefox" and the submenu action being called "Open URL" or something like that. That arrangement seems more standard and scalable.

Comment 40

[Tom Dyas]

Attachment: Add "Open URL" items to Services menu (take 2)

The patch has now been simplified tremendously through the use of nsICommandLineRunner.  The menu item in the Services menu is still "Open URL in {app_name}" because, as shown by one of the images posted in this bug, other Mac OS X web browsers use the same convention.

Open issue: Localization of the ServicesMenu.strings file.

Comment 41

[Tom Dyas]

Attachment: Force update of Service menu (v2)

Use this program to force update of Services menu without having to log out and then in again.  Compile command in source.

Comment 42

[Tom Dyas]

Mac OS X 10.6 has a general "Open URL" service that opens a selected URL in the default browser.  This feature may moot this bug since the only service proposed so far in my patch is a "Open URL in Firefox" service.  Thoughts?

Comment 43

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 44

[Alex Limi (:limi) — Firefox UX Team]

The Open URL case is handled by OS X now, are there any other services we should support? I've never used Services, so it's hard for me to give any recommendations here. :)

Comment 45

[Reuben Morais [:reuben]]

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #44)
> The Open URL case is handled by OS X now, are there any other services we
> should support?

We should support the general text services for selected text. Here's what I see on Sublime Text 2: http://cl.ly/Dvr2

Comment 46

[Justin Dolske [:Dolske]]

(In reply to Reuben Morais [:reuben] from comment #45)

> We should support the general text services for selected text. Here's what I
> see on Sublime Text 2: http://cl.ly/Dvr2

How often do you add C++ code to iTunes as a spoken track? ;-)

Comment 48

[tamer]

It is hard to believe that 15 years later, the right click menu still has no services option.

Comment 49

[Spegahsheen]

If I actuate Firefox's refresh function, Services work properly until I close and reopen Firefox. Then the items in Firefox/Services menu disappear after I closed and reran the application. Not so in every browser tab.
They are there and working correctly if the browser display the Help/Troubleshooting page. https://i.stack.imgur.com/QWhMi.jpg
But not in other pages. https://i.stack.imgur.com/E9pdd.jpg

I tried to run Firefox with the option "-NSDebugServices com.apple.mail" getting the following messages:
Mail/New Email With Selection (com.apple.mail) is enabled in the services menu and disabled in the context menu, by the standard Services policy.
Mail/New Email To Address (com.apple.mail) is enabled in the services menu and disabled in the context menu, by the standard Services policy.
Mail/New Email To Address (com.apple.mail) is disqualified because its send and/or return types cannot be handled by the requestor ChildView 0x11b6e4680, gecko child 0x11ba56800, frame {{0, 0}, {1580, 1040}}.
Mail/New Email With Selection (com.apple.mail) is disqualified because its send and/or return types cannot be handled by the requestor ChildView 0x11b6e4680, gecko child 0x11ba56800, frame {{0, 0}, {1580, 1040}}.
GVA info: Successfully connected to the Intel plugin, offline Gen9 
WebGL(0x12dc38000)::ForceLoseContext"

Firefox 50.1.0
OS X 10.11.6

Comment 50

[Stephen A Pohl [:spohl]]

macOS appears to implement this now. Let's open more targeted bugs for any remaining work.