Closed Bug 1699842 Opened 4 years ago Closed 3 years ago

Keep Firefox in Dock for macOS where windows would Pin without showing images

Categories

(Firefox :: Messaging System, enhancement, P2)

Desktop
macOS
enhancement

Tracking

()

VERIFIED FIXED
90 Branch
Iteration:
90.3 - May 17 - May 30
Tracking Status
firefox89 --- wontfix
firefox90 --- verified

People

(Reporter: adavis, Assigned: Mardak)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

Attachments

(7 files, 1 obsolete file)

Context and Ask
We've recently done work to make it easier for users to pin Firefox to their Windows taskbar. Let's provide the same ease to Mac users by making it just one click to add the Firefox launcher to their dock.

This could reduce confusion if the user still has the installer mounted and visible on their desktop.

It's unclear if this should just be done or run as an experiment. Our confidence level is very high due to the strength of evidence we have so we could save time by just building this however, I believe there would be value in understanding the exact impact that this work will have on our Mac users.

We should integrate the 1-click pinning/docking to the same touchpoints as we are on Windows.

Unknowns

  • Should this be an experiment or directly deployed? (can we do both with a holdback?)
  • Will users need to enter their passwords? (or use touchID)
  • Should we add this to the set to default API?
  • Can we detect if the browser is already pinned to avoid pinning again?

Other considerations
There is a Mac installer that will be made by the platform team in the future that will serve the purpose of helping Mac users who have not successfully installed. These two efforts are complementary but we should share any insights we get with them.

Severity: -- → S3
Priority: -- → P2
Depends on: 1709598

Alex, what API do you need for this? In bug 1709598 I'll add native (C-header) API, but perhaps you need JS API? If so, can you outline how you'd like it to look?

Flags: needinfo?(adavis)

The windows API is exposed on nsIWindowsShellService as 3 methods:

  • pin firefox
  • whether pinning firefox would work
  • if firefox is already pinned

https://searchfox.org/mozilla-central/rev/6371054f6260a5f8844846439297547f7cfeeedd/browser/components/shell/nsIWindowsShellService.idl#16-76

Having the "already pinned" is useful as it allows us to switch from "primary" (pin and default) to "default" messaging. The whether-it-will-work was needed on windows as there are various conditions, e.g., specific windows version requirement, that would prevent it from working, which we then also fall back to "default" messaging, but if the mac implementation works everywhere, we wouldn't need one.

These can be sync or async / return promises. Maybe on nsIMacShellService to match ?

Flags: needinfo?(adavis)

Hi Jonathan and Ed, is there any update on progress here? Still on track for Fx90?

Flags: needinfo?(jwatt)
Flags: needinfo?(edilee)

Hi Alex. The patch I have up for bug 1709598 will allow for this bug to be implemented using code like:

let dockSupport = Cc["@mozilla.org/widget/macdocksupport;1"].getService(Ci.nsIMacDockSupport);
if (!dockSupport.isAppInDock) {
  dockSupport.keepAppInDock();  // See .idl for optional args
}

Let me know if you need anything else to be able to proceed with this bug.

Flags: needinfo?(jwatt)
Flags: needinfo?(edilee)

We currently have these 6 strings that refer to taskbar:

default browser prompt
default-browser-prompt-message-pin = Keep { -brand-short-name } at your fingertips — make it your default browser and pin it to your taskbar.

about:welcome
[old?] onboarding-multistage-pin-default-help-text = This will pin { -brand-short-name } to taskbar and open settings
mr1-onboarding-set-default-pin-primary-button-label.title = Sets { -brand-short-name } as default browser and pins to taskbar

upgrade dialog
upgrade-dialog-new-primary-primary-button.title = Sets { -brand-short-name } as default browser and pins to taskbar
[old?] upgrade-dialog-new-primary-pin-button = Pin { -brand-short-name } to my taskbar
upgrade-dialog-new-primary-pin-alt-button = Pin to taskbar

We could skip one of the about:welcome as that’s pre-proton and one of the upgrade dialog as it’s the string before 3-screens. So for mac, we'll want at least 4 new strings and new pin/default images on upgrade onboarding, which we might also use for about:welcome?

Ana, which strings should we be making mac versions? And will we be changing about:welcome to have the "pin" then "default" in 90, which would then have new strings to land including "Pin to Taskbar" and "Pin Firefox to your taskbar" as well as potentially others based on the followup pin experiment and user studies?

Meridel, what should the mac versions say? The macOS UI shows a menu option of "Keep in Dock" so maybe just that, so Firefox buttons show "Keep in dock" and text with "…make it your default and keep in your dock" ? Also, if we do continue with the "primary browser" language which about:welcome explains with "and open settings" help text, I suppose we should have something similar for macOS's permission prompt (see attached)?

flod, these wording differences seem to suggest using fluent selectors as it's the same behavior but OS refers to the surfaces differently. Given that we have existing windows fluent strings, can/should the existing ones be migrated to a new string with selector?

upgrade-dialog-new-primary-keep-pin-button = { PLATFORM() ->
    [macos] Keep in dock
   *[other] Pin to taskbar
}

upgrade-dialog-new-primary-keep-pin-button = { PLATFORM() ->
    [macos] {nothing exists…? should this line be omitted? migration won't work?}
   *[other] {COPY_PATTERN(from_path, "upgrade-dialog-new-primary-pin-alt-button")}
}
Flags: needinfo?(mwalkington)
Flags: needinfo?(francesco.lodolo)
Flags: needinfo?(amedinac)
Iteration: --- → 90.3 - May 17 - May 30
Assignee: nobody → edilee
Blocks: 1686284

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

flod, these wording differences seem to suggest using fluent selectors as it's the same behavior but OS refers to the surfaces differently. Given that we have existing windows fluent strings, can/should the existing ones be migrated to a new string with selector?

Migrating partial strings is not an option.

If you do, that partial translation would be treated as translated, with an empty macOS variant.

Flags: needinfo?(francesco.lodolo)

Ed, is the ask specifically for the permission prompt strings? Can you tell me when and how this is surfaced?

Flags: needinfo?(mwalkington) → needinfo?(edilee)
  1. Either exact strings that would use "keep to dock" or general approach I should take to convert strings like "pins it to your taskbar" (e.g., replace "pin" with "keep" and "taskbar" with "dock" while keeping appropriate subject/verb agreement and "other" words)

  2. The macOS permission prompt shows up when firefox tries to set itself as the default browser. The strings mentioning "open settings" were added as part of "primary browser" of pre-mr1 about:welcome which did both pin and set default to give users a sense of what to expect. (see attached) Although maybe this is not as important right now as none of default prompt, upgrade dialog nor mr1 about:welcome mention "settings."

Flags: needinfo?(edilee) → needinfo?(mwalkington)

Meridel, I also noticed at least in the review comments for the API implementing this on macOS, "dock" is consistently referred to as "Dock"

A quick search does seem to confirm Dock is always (?) referred to as a proper noun at least from apple
https://www.google.com/search?q=dock+site%3Aapple.com

Whereas windows' taskbar can be lowercase
https://www.google.com/search?q=taskbar+site%3Amicrosoft.com

Thanks, Ed. When are we looking to ship/what is the deadline for strings?

Flags: needinfo?(mwalkington) → needinfo?(edilee)
Flags: needinfo?(edilee)
Flags: needinfo?(amedinac)
Attached image example mac upgrade dock no image (obsolete) (deleted) —

(In reply to Meridel [:meridel] from comment #11)

Thanks, Ed. When are we looking to ship/what is the deadline for strings?

String freeze for 90 is this Friday 28th.

With bug 1712802 changing about:welcome "primary browser" to "pin" without image, I'll probably end up removing the images from the upgrade dialog and updating the new strings at the same time in this bug. So we don't need to update the "primary browser" related strings for mac and seems like we'll have these new strings…

default browser prompt
message = Keep Firefox at your fingertips — make it your default browser and keep it in your Dock.

about:welcome
title = Keep Firefox in your Dock for easy access
button = Keep in Dock

upgrade dialog
title = Say hello to the new Firefox every time you browse
button = Keep in Dock

Meridel, looks like those 5 example strings above need to be finalized (see examples in attachment 9223499 [details] for prompt and attachment 9223500 [details] for upgrade dialog) -- no need for "settings"/"permission" and any additional adjustments you would want to other screens/prompts, e.g., "Make Firefox your default browser?" title or "Get speed, safety, and privacy every time you browse." subtitle, by end of this week.

Flags: needinfo?(mwalkington)
Summary: Pin Launcher to Dock In Mac with An Opt-In → Keep Firefox in Dock for macOS where windows would Pin without showing images
Attached image example primary prompt (deleted) —
Attached image example upgrade dialog (deleted) —
Attachment #9223441 - Attachment is obsolete: true

(In reply to Francesco Lodolo [:flod] from comment #7)

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

flod, these wording differences seem to suggest using fluent selectors as it's the same behavior but OS refers to the surfaces differently. Given that we have existing windows fluent strings, can/should the existing ones be migrated to a new string with selector?

Migrating partial strings is not an option.

If you do, that partial translation would be treated as translated, with an empty macOS variant.

Given this seems to be touching pretty much all the dialog, I'd suggest to use different strings instead of a PLATFORM() selector. At least, the strings for Windows would remain translated.

EDIT: never mind, didn't realize that most of the Windows strings were changing as well.

Update ShellService to also check mac pinned but only from the main process, so have AboutWelcomeChild request pinned for use in getDefaults and prepareContent. Remove windows images and consolidate back to single shared css. Split out pin strings to own screen/section and use PLATFORM. Update default screen and default prompt strings too.

Attached image Make Primary modal for MacOS_90.png (deleted) —

Strings for the default/primary prompt modal:

Title: Make {Brand shorter name} your primary browser?
Body: Keep {Brand shorter name} at your fingertips — make it your default browser and keep it in your Dock.
Checkbox label: Don’t show this message again
Primary button: Make primary browser
Secondary button: Not now

Flags: needinfo?(mwalkington)
Blocks: 1712802
Pushed by elee@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a3f51885047c
Keep Firefox in Dock for macOS where windows would Pin without showing images r=pdahiya,flod
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
Flags: qe-verify+

I have verified this enhancement and I can confirm the following:

  • Default Browser Prompt:
    • The Keep Firefox at your fingertips — make it your default browser and keep it in your Dock. message is displayed.
    • A checkbox followed by the `Don't show this message again" string is displayed under the message.
    • The Not now and Make primary browser buttons are displayed in the bottom part of the prompt.
  • "about:welcome" page:
    • The Keep Firefox in your Dock for easy access title is displayed.
    • The Keep in Dock button is displayed under the title.
  • Upgrade modal:
    • The Keep Firefox in your Dock title is displayed.
    • The Keep in Dock primary button is displayed in the bottom part of the modal.

Verified using the latest Firefox Beta (90.0b3 Build ID - 20210603185634) installed on macOS 10.15.7.

Status: RESOLVED → VERIFIED
Blocks: 1716884
No longer depends on: 1721603
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: