Similar to bug 1685213 for windows is-pinned-to-taskbar, we can use the API added in bug 1709598 to get a baseline and also measure the effect of keeping firefox in Dock (about:welcome, upgrade dialog, default browser prompt).

os.environment.is_taskbar_pinned scalar set here:
https://searchfox.org/mozilla-central/rev/c0f286b1f541c675bbe052b21bdefa80d150ec35/browser/components/BrowserGlue.jsm#2320-2331

Add BrowserGlue task and telemetry Scalar matching is_taskbar_pinned.

Comment on attachment 9226198 [details]
Data Review Request Form

Load-balance to Travis

Comment on attachment 9226198 [details]
Data Review Request Form

Data Review

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?

Yes, in Scalars.yaml and through the Probe Dictionary

2. Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, via the normal Telemetry preference

3. If the request is for permanent data collection, is there someone who will monitor the data over time?

N/A, collection set to end in v97

4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2: User Interaction

5. Is the data collection request for default-on or default-off?

default-on

6. Does the instrumentation include the addition of any new identifiers?

No

7. Is the data collection covered by the existing Firefox privacy notice?

Yes

8. Does the data collection use a third-party collection tool?

No

Result

data-review+

https://hg.mozilla.org/mozilla-central/rev/98cbc5855715

I have verified this enhancement and I can confirm that the os.environment.is_kept_in_dock scalar is successfully displayed in the "about:telemetry#scalars-tab" page. The scalar has the value true if Firefox is kept to Dock and false if is not.

Verified using the latest Firefox Nightly (91.0a1 Build ID - 20210615214502) installed on macOS 10.15.7 and macOS 11.4

Looking among mac clients on eligible release versions (91+) that send us a main ping, only about 40% of them seem to have this probe set one way or the other (the rest aren't reporting it) [1]

I am running nightly 94.0a1 buildid 20210923145200 and I have mac kept in the doc, according to about:telemetry I do not have the probe set either.

Are there some common cases where we would expect this probe to be unset (neither true or false)?

[1] https://sql.telemetry.mozilla.org/queries/82117/source#203479

(In reply to Leif Oines [:loines] from comment #8)

only about 40% of them seem to have this probe set

jwatt, do you know if there might be common exceptions when trying to access nsIMacDockSupport.isAppInDock ? I see some stuff about Plists, but are those actually rare/exceptional?

(In reply to Leif Oines [:loines] from comment #8)

according to about:telemetry I do not have the probe set either.

I believe the implementation here basically matches bug 1685213 for os.environment.is_taskbar_pinned. I think you mentioned something about startup/delay before the probe is set? Did we notice this missing for windows or maybe the close/launch behavior is different enough on macOS?

Yes, because you added this to _scheduleStartupIdleTasks(), it should nearly always run. [1]

But a thing to remember is that Telemetry scalars are cleared once they're sent in a ping, so you may have to aggregate a whole session id, or just pull out the first subsession, if you want to use the value from when this scalar was set (at the beginning of the session). I modified the query from comment 8 with WHERE payload.info.subsession_counter = 1, that seems to fix it.

[1] This runs as an idle task after all windows and tabs are restored (according to the comment). The alternate _scheduleBestEffortUserIdleTasks() (doc) has given us trouble, that requires the user to be idle for a while and has a pretty good chance of never running in a session or for a user (see bug 1660198 comment 6 and bug 1660198 comment 9, it might be from 9% to 20%).

(In reply to Leif Oines [:loines] from comment #8)

I am running nightly 94.0a1 buildid 20210923145200 and I have mac kept in the doc, according to about:telemetry I do not have the probe set either.

What happens when you run Cc["@mozilla.org/widget/macdocksupport;1"].getService(Ci.nsIMacDockSupport).isAppInDock in the Browser Console?

(In reply to Ed Lee :Mardak from comment #9)

jwatt, do you know if there might be common exceptions when trying to access nsIMacDockSupport.isAppInDock ? I see some stuff about Plists, but are those actually rare/exceptional?

Sorry for the very late reply. Comment 8 indicates we're hitting the error cases in nsMacDockSupport::GetIsAppInDock very frequently. It would be good to figure out why that happens, but since that API can throw it would be better to have a tri-state probe (an additional 'unknown' value) rather than a boolean regardless of the reason there.