1785814 - The "os.environment.is_taskbar_pinned_private" scalar is set to "false" even if the "Pin Private Window" shortcut is pinned to the taskbar

Status: VERIFIED FIXED

(Firefox :: Shell Integration, defect, P1)

Description

[Marius Coman [:mcoman], Ecosystem QA]

Attachment: rec of the issue.gif

[Notes]:

• This issue might affect the "Pin Private Window" modal from the MR Onboarding flow for the existing users as the modal is displayed even if the "Private Window" shortcut is already pinned to the taskbar.

[Affected versions]:

• Firefox Nightly 105.0a1 - Build ID: 20220612185901

[Affected Platforms]:

• Windows 10 x64

[Prerequisites]:

• Have the following prefs in the "about:config" page:
  • "nimbus.debug" pref set to "true".
  • "browser.promo.pin.enabled" set to "true"
• Have the "Remote Settings Devtools" add-on installed from here.

[Steps to reproduce]:

1. Open the browser with the profile from the prerequisites.
2. Click the "Remote Settings Devtools" tollbar button from the right part of the toolbar.
3. Switch the environment to "Stage" and restart the browser.
4. Navigate to the "about:studies?optin_slug=cmuresandesktop-nimbus-exploration-080522&optin_branch=treatment-a&optin_collection=nimbus-preview" URL.
5. Open a "Private Window" and click the "Pin to taskbar" button.
6. Restart the browser and navigate to the "about:telemetry" page.
7. Search for the "os.environment.is_taskbar_pinned_private" scalar and observe the value.

[Expected result]:

• The value of the "os.environment.is_taskbar_pinned_private" scalar is set to "true".

[Actual result]:

• The value of the "os.environment.is_taskbar_pinned_private" scalar is set to "false".

[Regression window]:

• Considering that this issue is not reproducible on Firefox Beta 104 using the Mozregression tool I have managed to find the following regression window:
  Last good revision: 113593df627273c8e66f58bf735c38ad7e937f38
  First bad revision: 23d27ffb8a811e38a46621aa06044ff3acaac2b9
  Pushlog:
  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=113593df627273c8e66f58bf735c38ad7e937f38&tochange=23d27ffb8a811e38a46621aa06044ff3acaac2b9

From the pushlog it seems that Bug 1761291 might have caused this regression.

@Ben could you please take a look over this?

[Additional Notes]:

• The "os.environment.is_taskbar_pinned" is correctly recorded for the normal browsing shortcut.
• Attached a screen recording of the issue.

Comment 1

[[e-mail] (:bhearsum)]

It's definitely plausible that the bug in that range broke this. I did test it, but perhaps I overlooked something. I'll dig into this ASAP.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1761291

Comment 3

[[e-mail] (:bhearsum)]

This is definitely a real bug, and the STR is much simpler:

1. Install the latest Firefox Nightly
2. Run ShellService.pinToTaskbar(true) in the Browser Console
3. Restart Firefox

Expected result:
is_taskbar_pinned_private should be true in about:telemetry

Actual result:
is_taskbar_pinned_private is false

I'll get a patch with a fix up ASAP. I'd like this to make it before 105 uplifts to Beta.

Comment 4

[[e-mail] (:bhearsum)]

Attachment: Bug 1785814: The "os.environment.is_taskbar_pinned_private" scalar is set to "false" even if the "Pin Private Window" shortcut is pinned to the taskbar r?bytesized!

In an ideal world we'd pass in the privateBrowsing flag and use that to both find the correct AUMID and binary to compare against, but because this code runs off main thread, and finding AUMIDs requires prefs access - we must pass in the AUMID from elsewhere.

Given that, checking that the target of the shortcut is one of the two possible Firefox entry points, and ensuring it matches the requested AUMID, seems reasonable.

There's no technical reason why we couldn't pass in the privateBrowsing flag to use in determining which binary we're looking for -- but I don't think it really adds any real benefit, and passing both it an the AUMID makes the interface more confusing.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/23d7e6fa8250
The "os.environment.is_taskbar_pinned_private" scalar is set to "false" even if the "Pin Private Window" shortcut is pinned to the taskbar r=bytesized

Comment 6

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/23d7e6fa8250

Comment 7

[Marius Coman [:mcoman], Ecosystem QA]

I have verified that this issue is no longer reproducible with the latest Firefox Nightly (105.0a1 Build ID - 20220819095050) installed on Windows 10 x64. Now, I can confirm that the "os.environment.is_taskbar_pinned_private" scalar is set to "true" if the "Private Window" shortcut is pinned to the taskbar.