Closed Bug 104331 Opened 23 years ago Closed 1 year ago

Add items to Services menu on Mac OS X

Categories

(Firefox :: General, enhancement, P3)

Product:
Firefox
Component:
General
Platform:
All
macOS
Type:
enhancement

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mike, Unassigned)

References

Details

Attachments

(9 files, 4 obsolete files)

Screenshot of Minefield's "Services" Menu
255.57 KB, image/png
Details
My 'Services' menu
82.77 KB, image/png
Details
observing breadcrumb trails within menus
405.52 KB, image/png
Details
focusing on the waste of vertical menu space caused by multiple menu items for a single action to multiple applications
17.29 KB, image/png
Details
Open URL in
22.60 KB, image/png
Details
preferring an application-oriented single top level menu item + multiple subs approach to multiple commands
348.81 KB, image/png
Details
maybe half of one level of my Services menu
22.44 KB, image/png
Details
Add "Open URL" items to Services menu (take 2)
24.03 KB, patch
Details | Diff | Splinter Review
Force update of Service menu (v2)
277 bytes, text/plain
Details 
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.
Confirming as an RFE to explore ways to utilize OS X's "Services" menu.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Add items to services menu on Mac OS X → Add items to Services menu on Mac OS X
->xpapps
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Assignee: pchen → pinkerton
pink, would this belong to you?
mike 'osx dumping ground' pinkerton, at your service ;)

accepting for future.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
QA Contact: sairuh → petersen
nominating for buffy.
Keywords: nsbeta1
Adding sfraser to cc: list as he's doing some related work in Chimera
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Product: Core → Mozilla Application Suite
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?
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.
Assignee: mikepinkerton → jag
Status: ASSIGNED → NEW
QA Contact: chrispetersen
Target Milestone: Future → ---
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.
Attached file Force update of Services menu (obsolete) — 
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.
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?
Attachment #351116 - Attachment is obsolete: true
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.
Attachment #351568 - Attachment is obsolete: true
Attachment #352982 - Flags: review?(joshmoz)
(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.
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.
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.
Keywords: uiwanted
Here is the requested screenshot of the "Services" menu with the items from the patch showing.
(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.)
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
(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.
@ 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.
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
Attached image 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).
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.
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.
Attached image 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.
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.
Hardware: PowerPC → All
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.)
(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.
> 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
> * all processor services of Flock should be sub to the Firefox menu 

Spot the deliberate mistake. Sorry!
> 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!
Attachment #352982 - Flags: review?(joshmoz) → review-
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.
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?
Also, I need UI input:  Should the only services menu item supported by Firefox be a "Open in Firefox" item?
(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.
Assignee: jag → nobody
Component: UI Design → General
Product: SeaMonkey → Firefox
QA Contact: general
Assignee: nobody → tdyas
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.
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.
Attachment #352982 - Attachment is obsolete: true
Attachment #383395 - Flags: review?(joshmoz)
Use this program to force update of Services menu without having to log out and then in again.  Compile command in source.
Attachment #351117 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Firefox 3.6a1
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?
Attachment #383395 - Flags: review?(joshmoz)
Assignee: tom.dyas → nobody
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.
Status: ASSIGNED → NEW
Depends on: 135268
Target Milestone: Firefox 3.6a1 → ---
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. :)
Keywords: uiwanted
(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
(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? ;-)
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
See Also: → 1470624
See Also: → 660452
See Also: → 1284890
Severity: normal → S3

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

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: