Should this be marked as an accessibility issue? Users unaware of the difference between Firefox (where Services are in Firefox menu) and Chrome (where you right click on text and can see the Services submenu) may not realize text-to-speech is possible on Firefox.

It's not so much about what chrome does, but rather that having services in the contextual menu is the default in macOS apps like TextEdit, Pages and obviously also Safari. Chrome just follows that. So firefox sticks out as very non-mac like in that regard.

I get the impression that more than one comment seem to assume that Application Menu > Services is a full feature replacement for the context submenu, only less convenient. How would you send the URL of a link to a service with that method? I can imagine that's not an uncommon use case when using macOS services in a browser, and that this is not just an unmet expectation of where functionality can be found, but actual missing functionality.

Came here to say the above ^^

Highlighting text and going to the services menu in "Firefox" is certainly less convenient, but not a huge deal. But I know of no way to do this with links. In Chrome or Safari I can right-click on a link and go to services to send that URL (not the text) to that service, but not in Firefox (AFAIK)

Would it be possible to bump the priority on this 12-year-old issue? Context menu Services is a significant power user feature in macOS, and I think the type of Mac users who utilize that feature are more likely to be interested in switching to Firefox than a typical light-duty Mac user. The Services menu in the Firefox menu isn't a direct replacement for the context menu.

I've been exploring switching Firefox to my default web browser, but unfortunately this may be a dealbreaker for me :( Firefox is so close to feeling like a native macOS app these days, but the absence of Services in the context menu is a major omission in my eyes.

I'm afraid I don't have the development experience or knowledge to work on this directly, but I would be happy to volunteer as a tester if that would be helpful.

Thank you Isaac, well said.

Please re-consider the priority of this. An app that has no proper integration with its Host OS is not a fully functional app for most users.

Looks like this was explicitly disabled back when bug 1698997 landed, but I can't see the reason for that documented anywhere; presumably there's some more work that needs to be done before it would function properly. I'm moving this to the component that handles those system-native context menus in hopes that they'll have the right context to evaluate this.

I'm going to n-i myself to take a look. Markus, do you remember why we disabled this context menu in bug 1698997?

Just because it was new stuff that we didn't have before, and because we had a deadline and it was easier to keep the existing behavior as much as possible. If everything just works if we re-enable these items, that's great. But I think I found at least one case where the items appeared in cases where they were unexpected, I don't remember when though.

Here is a try build with this context menu enabled. In my very limited testing, none of the services seem to work correctly. If you are interested in taking this for a spin and letting us know if any of the services are working at this time, that would be great info to have. You may have to manually launch the try build from System Settings > Privacy & Security (or right click and open) since the build isn't signed with our official certificate:

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/PN7FCCYHQd6_p5iTXlYsbA/runs/0/artifacts/public/build/target.dmg

Happy to see some progress here, thanks all!

Stephen, I just tried the build and I'm not having any luck getting the services to work either. Some of them don't do anything at all when I click them, and others give me two error dialogs at the same time:

The "Service Name" service could not be used."

There was a problem with the input to the Service.

In the terminal with a self-built version of :spohl's patch, I see:

2023-02-11 20:21:26.870 firefox[5532:5354207] Object ChildView 0x11911a500, gecko child 0x11911a200, frame {{0, 0}, {1280, 902}} could not or did not write the selection to the pasteboard in preparation for a service request

After some debugging, it seems we bail out in this condition

// Make sure that the service will accept strings or HTML.
if (![types containsObject:[UTIHelper stringFromPboardType:NSPasteboardTypeString]] &&
    ![types containsObject:[UTIHelper stringFromPboardType:NSPasteboardTypeHTML]]) {
  return NO;
}

NSLog of types produces:

2023-02-11 20:29:34.511 firefox[9091:5364403] (
    NSStringPboardType
)

I tried various incantations to get the condition to pass. AFAICT NSStringPboardType is deprecated by Apple, but apple's still asking us for it 🤷. Frankly, for someone not familiar with cocoa, apple's docs are clear as mud. The writeSelectionToPasteboard docs say both that types is an NSArray<NSPasteboardType> *, but also that it's "An array of strings describing the types of data to write.". Presumably this is because NSPasteboardType is typedef'd to NSString. But we call UTIHelper stringFromPboardType, which produces a different NSString (things like public.utf8-plain-text). So then we can't find it in types and just tell apple "no".

I don't know what the "right" solution is (honest, I tried a few different incantations), and it's definitely not what I'm about to paste, but after applying a patch like this on top of :spohl's patch:

diff --git a/widget/cocoa/nsChildView.mm b/widget/cocoa/nsChildView.mm
--- a/widget/cocoa/nsChildView.mm
+++ b/widget/cocoa/nsChildView.mm
@@ -4454,16 +4454,19 @@ static CFTypeRefPtr<CFURLRef> GetPasteLo
 
 - (BOOL)writeSelectionToPasteboard:(NSPasteboard*)pboard types:(NSArray*)types {
   NS_OBJC_BEGIN_TRY_BLOCK_RETURN;
 
   nsAutoRetainCocoaObject kungFuDeathGrip(self);
 
   // Make sure that the service will accept strings or HTML.
   if (![types containsObject:[UTIHelper stringFromPboardType:NSPasteboardTypeString]] &&
+      ![types containsObject:NSStringPboardType] &&
+      ![types containsObject:NSPasteboardTypeString] &&
+      ![types containsObject:NSPasteboardTypeHTML] &&
       ![types containsObject:[UTIHelper stringFromPboardType:NSPasteboardTypeHTML]]) {
     return NO;
   }
 
   // Bail out if there is no Gecko object.
   if (!mGeckoChild) return NO;
 
   // Transform the transferable to an NSDictionary.

I at least got the "search with google" safari service to work, for text selection.

Tested on macOS 12 Monterey only, I didn't test any other functionality, ymmv, no warranty, usual disclaimers... But hopefully this is still somewhat helpful.

Note that for link context menus (see comment 12), the Services menu still doesn't appear (if there's no selection). I don't really understand the request in bug 1284890 and if that's just about text selection inside text areas / input fields (which I assume works the same way as text selection outside such form elements), or if there's other stuff needed there. Either way I assume the link stuff would need further work as I noticed there's some "interesting" selection cache sharing happening on the gecko side to make the Services menu work, which this is piggybacking on. I imagine we'd need to do something similar when a context click happens on a link, or something - but perhaps that exists elsewhere already.

I am planning to switch to firefox as my default browser, but unavailability of services in context menu is stopping me. Mac services in context menu is a blessing in other browsers. Please prioritize

(In reply to :Gijs (he/him) from comment #20)

In the terminal with a self-built version of :spohl's patch, I see:

I don't know about Apples API, but I can confirm that all my Automation Services work with the patches you mention applied. Thank You.

I see that there is an issue with the current published build, Firefox 111.0.1, which is in need of fix for Bug 1822845.

Hopefully this final missing patch will be added real soon.

Once again, Thank you.

Thank you for your comment. I'm just now realizing that this might have been broken due to bug 1822845. I'm going to take another look.

(In reply to Stephen A Pohl [:spohl] from comment #23)

Thank you for your comment. I'm just now realizing that this might have been broken due to bug 1822845. I'm going to take another look.
I pulled in the latest published changes (hg pull -u got me changeset 20fd1832c181).

When the previously provided patch above was rejected (patch -p1 -i ../Gijs.patch), a cursory review
of widget/cocoa/nsChildView.mm saw the inclusion of NSStringPboardType , similar to the above:

  // Make sure that the service will accept strings or HTML.
  if (![types containsObject:[UTIHelper stringFromPboardType:NSStringPboardType]] &&
      ![types containsObject:[UTIHelper stringFromPboardType:NSPasteboardTypeString]] &&
      ![types containsObject:[UTIHelper stringFromPboardType:NSPasteboardTypeHTML]]) {
    return NO;
  }

So built nightly with myMenu.allowsContextMenuPlugIns = NO; commented out in widget/cocoa/nsMenuX.mm.
And now Select and Services Menu or Personal Shortcut Keys to Automated services are working. Fantastic.
:-)

And now Select and Services Menu or Personal Shortcut Keys to Automated services are working.
I mean Selecting Text and using Right Click now brings up a menu
with the Services and my Automation Services work. And Automation
Services also work when using Shortcut keys too.
Nothing appears broken. Even checked that spell-check still worked when writing this :-)

https://hg.mozilla.org/mozilla-central/rev/93996ea3c7de

Should we add this to the Fx113 relnotes? Please nominate if yes!

Release Note Request (optional, but appreciated)
[Why is this notable]: The macOS Services menu is now also exposed in the context menu.
[Affects Firefox for Android]: No
[Suggested wording]: Mac users can now access macOS Services directly from the context menu.
[Links (documentation, blog post, etc)]: n/a

I think this fixes bug 1284890, but we probably want a follow-up bug for links? (cf comment 11 / comment 12)

(In reply to :Gijs (he/him) from comment #31)

I think this fixes bug 1284890, but we probably want a follow-up bug for links? (cf comment 11 / comment 12)

It does indeed fix bug 1284890. The reason why this doesn't work for links yet is due to bug 1751335 and will start working once that's fixed.

Added to the Fx113 Nightly relnotes, thanks.