1328994 - Services menu in MacOSX shows "no services apply"

Status: RESOLVED WORKSFORME

(Core :: Widget: Cocoa, defect, P3)

Description

[aduitsis]

Attachment: Screen Shot 2017-01-05 at 10.42.51 PM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

Select some text in any page. Go to Firefox -> services in the macosx menubar. The submenu says "no services apply".


Actual results:

The submenu says "no services apply" and there are no actionable items in it.


Expected results:

There should be several entries (e.g. lookup with dictionary, search with Google, etc) which could be applied to the selected text. This used to be the case e.g. a month ago as far as I can tell. At some point, the services menu stopped being populated. Most likely between Firefox 50.0 and 50.1.

This is a particularly unpleasant bug, as in macosx you have extremely useful shortcuts using the services facility, e.g. by pressing ctrl-option-command-d while a word is selected, you can look up that word in the dictionary. And so on.

Others have encountered the same bug http://apple.stackexchange.com/questions/264348/firefox-services-menu-void, but I couldn't ascertain whether they have opened a bug report. Hence, I'm doing it.

Comment 1

[Loic]

Gijs, any thoughts?

Comment 2

[Marcia Knous [:marcia]]

Attachment: Screenshot of Services using Nightly

Nightly seems to show the Services menu, but I noticed on my machine beta does not.

Comment 3

[:Gijs (he/him)]

I have no ideas. This worked for me on 51, and then I launched 50.1 and it was broken there, and I cmd-tab'd back to 51 and then it was broken there too. I don't know how this stuff is implemented but it looks like something's going pearshapes. Markus knows more about this stuff than I do, maybe he has ideas?

Comment 4

[Markus Stange [:mstange]]

Very strange. I don't have any ideas either.

We'll need good steps to reproduce so that somebody can look into this.

Comment 5

[Tracy Walker [:tracy]]

Gijs' steps to reproduce confirmed.

0) Launch both Fx 50 and latest Nightly.
0a) Note Nightly > Services works correctly
1) On Fx 50 got to Firefox > Services
1a) Notice broken entry as reported.
2) On Nightly go to Nightly > Services

results on Nightly are that it is now broken.

Comment 6

[André Reinald]

This sounds to me like its related to e10s.
I run 50.1 with e10s and I see the issue happening.
BUT if I select part of the URL in the address bar, the Services menu behaves like expected.
I guess the address bar is handled by the main process, and that may explain the different behavior.
I will check myself a bit later, unless someone checks first.

Comment 7

[:Gijs (he/him)]

(In reply to André Reinald from comment #6)
> This sounds to me like its related to e10s.
> I run 50.1 with e10s and I see the issue happening.
> BUT if I select part of the URL in the address bar, the Services menu
> behaves like expected.
> I guess the address bar is handled by the main process, and that may explain
> the different behavior.
> I will check myself a bit later, unless someone checks first.

It's possible, but I use beta without e10s enabled. Don't know if e10s being enabled in nightly with the steps from comment #3 / comment #5 is going to make a difference because I don't know anything about OSX's Services architecture.

Comment 8

[André Reinald]

Checked more thoroughly with FF 50.1 AND Nightly on MacOS 10.12.2.

1. Menu "Services" LOOKS
1a. In FF, menu "Services" LOOKS normal only when I select text in the address bar, but it's empty when I do so in a web page (this bug).
1b. In Nightly, menu "Services" LOOKS normal when I select text either in the address bar OR in a web page.

2. The text is NOT TRANSFERRED to the selected application, neither in FF nor in Nightly (I tried both "New Sticky Note" and "New Email"). This is not the same bug, but I guess we could call it related at least. I haven't seen it opened in bugzilla.

3. I get the same results with or without e10s in Nightly (only tried in e10s in FF 50.1).

Note: I can't confirm step 2 from comment 5, Services menu from Nightly isn't affected by what happened in FF.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to André Reinald from comment #8)
> 2. The text is NOT TRANSFERRED to the selected application, neither in FF
> nor in Nightly (I tried both "New Sticky Note" and "New Email"). This is not
> the same bug, but I guess we could call it related at least. I haven't seen
> it opened in bugzilla.

I came here to a file a bug about the above and discovered this bug. In my testing the selection is transferred in every version before 53.

Comment 10

[:Gijs (he/him)]

(In reply to Panos Astithas [:past] from comment #9)
> (In reply to André Reinald from comment #8)
> > 2. The text is NOT TRANSFERRED to the selected application, neither in FF
> > nor in Nightly (I tried both "New Sticky Note" and "New Email"). This is not
> > the same bug, but I guess we could call it related at least. I haven't seen
> > it opened in bugzilla.
> 
> I came here to a file a bug about the above and discovered this bug. In my
> testing the selection is transferred in every version before 53.

Can you find a regression window for this? It might be worth its own bug...

Comment 11

[Markus Stange [:mstange]]

The initial bug was filed against Firefox 50, which did not have a working Services menu when e10s was enabled.
Bug 1261299 fixed that in 51. Since then the Services menu is consistently populated.

However, according to comment 3 and comment 5, clicking items in the menu only worked intermittently in Firefox 51.

Starting with Firefox 53, clicking items in the services menu seems to be consistently broken - the selected text is not passed to the service. Bug 1361116 has been filed about this last regression.
Once bug 1361116 is fixed, we should re-check whether the STR in comment 5 still work (and resolve this bug if not).

Comment 12

[Stephen A Pohl [:spohl]]

Bug 1361116 now has a patch but isn't expected to change anything here. I tested this some more and I found that this intermittent behavior seems to be due to a mistake in our handling of selections. We currently only intend to display services if there is a selection[1]. If there is no selection, the services menu should show "No Services Apply". However, I noticed that double-clicking on a website will set |sSelectionCache|[2] to a transferable regardless of whether or not any text had actually been selected. If the user then selects a service like the dictionary, the console will print the following error:

2017-05-17 18:31:53.881 firefox[11614:119418] Pasteboard contained types (
), but service expects types (
    NSStringPboardType
)

It looks like we need to do either of two things:
1. Leave |sSelectionCache| null if no text had actually been selected. The services menu will then show "No Services Apply"
2. If it is intentional that we set |sSelectionCache| when no text had actually been selected, we should set an empty string for NSPasteboardTypeString in the transferable. This will avoid the console error above, but a user might still think that the services menu is only working intermittently because it is hard to tell when |sSelectionCache| is set with no actual text selected vs. |sSelectionCache| not being set.

Note that I did not need to run Firefox 50 to reproduce the "no services apply" in the services menu, as this seems to be the intentional behavior when no selection is set.

Markus, not sure if you can tell off-hand which way to proceed? I will not be able to pick this up anytime soon, but maybe this can help someone else get started.

[1] https://dxr.mozilla.org/mozilla-central/rev/85e5d15c31691c89b82d6068c26260416493071f/widget/cocoa/nsChildView.mm#6242-6243
[2] https://dxr.mozilla.org/mozilla-central/rev/85e5d15c31691c89b82d6068c26260416493071f/widget/cocoa/nsClipboard.mm#694

Comment 13

[Markus Stange [:mstange]]

(In reply to Stephen A Pohl [:spohl] from comment #12)
> 1. Leave |sSelectionCache| null if no text had actually been selected.

This sounds like the right thing to do.

> because it is hard to tell when |sSelectionCache| is
> set with no actual text selected

Why is that?

Comment 14

[Stephen A Pohl [:spohl]]

(In reply to Markus Stange [:mstange] from comment #13)
> (In reply to Stephen A Pohl [:spohl] from comment #12)
> > 1. Leave |sSelectionCache| null if no text had actually been selected.
> 
> This sounds like the right thing to do.
> 
> > because it is hard to tell when |sSelectionCache| is
> > set with no actual text selected
> 
> Why is that?

Since no text is visibly selected, the user has no visual cue to tell that |sSelectionCache| is non-null and that the Services will appear in the menu. I agree that option 1 seems like the right fix.

Comment 15

[André Reinald]

Works for me on FF 56.0 / Mac OS 10.13 (e10s enabled).
Services Menu works as expected (not only looks as expected) with text selected :
- in the address bar,
- in the search field,
- on static text in a page,
- on editable text/fields in a page.
If it works for others maybe we can close the bug?

Comment 16

[Stephen A Pohl [:spohl]]

The issue here is that the menu shows services in the services menu when no text is selected. From comment 12 (and discussed in comment 13 and comment 14), we should do the following:
> 1. Leave |sSelectionCache| null if no text had actually been selected. The services menu will then show "No Services Apply"

You can reproduce this on about:home:
1. Open about:home
2. Double-click on the page, making sure that no text is selected.
3. Notice that the services menu displays services. I should display "No Services Apply".

Comment 17

[André Reinald]

(In reply to Stephen A Pohl [:spohl] from comment #16)
> The issue here is that the menu shows services in the services menu when no text is selected.

Shouldn't we then rephrase the title of this bug?

> You can reproduce this on about:home:
> 1. Open about:home
> 2. Double-click on the page, making sure that no text is selected.
> 3. Notice that the services menu displays services. I should display "No Services Apply".

I just checked with those steps. Actually, on my side, the services menu DOES display "No Services Apply" when no text is selected, and displays applicable services when text is selected. Everything behaves as expected.

Maybe we need additional people to try those STRs with current Mac OS/FF?

Comment 18

[Stephen A Pohl [:spohl]]

This is intermittent and heavily depends on where you double-click. To fix this bug, when a selection contains anything other than a non-empty string, we should treat it as "nothing is selected" for the purpose of the services menu. This is achieved by leaving or setting the |sSelectionCache| to null.

Comment 19

[André Reinald]

Ovidiu, I can't reproduce this bug on 10.13.
Are you still able to reproduce this on 10.11 or 10.12?
Thanks.

Comment 20

[ovidiu boca[:Ovidiu]]

Hi,
I retested this on Mac OS X 10.10 with FF Nightly 58.0a1(2017-10-16) and with FF 56 release and I can't reproduce this issue.

Comment 21

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 22

[Isaac Nelson]

This does not appear to be an issues in Firefox 106.0.5 on macOS 10.14.6. The Services sub-menu of the Firefox menu works as expected for me.

Comment 23

[:Gijs (he/him)]

Let's close this out and we can reopen or file new bugs if this is still visible.