Closed Bug 1621696 Opened 5 years ago Closed 5 years ago

Windows Default Browser Agent - Phase 2 - Windows 10 toast notification API integration

Categories

(Toolkit :: Default Browser Agent, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla80
Tracking Status
firefox80 --- fixed

People

(Reporter: nalexander, Assigned: bytesized)

References

Details

Attachments

(13 files, 2 obsolete files)

47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
141.71 KB, image/png
Details
314.73 KB, image/png
Details
41.69 KB, image/png
Details
47 bytes, text/x-phabricator-request
Details | Review

This ticket tracks implementing the mechanics of notification display for the Windows Default Browser Agent (phase 2): creating and displaying Windows 10 toast notifications, registering and reacting to actions, etc.

There's a nice single-file wrapper library around this functionality that we might choose to incorporate: https://github.com/mohabouje/WinToast.

See Bug 1607833 for the notification designs.

Blocks: 1607833
Assignee: nobody → nalexander
Status: NEW → ASSIGNED
Group: mozilla-employee-confidential

One technically new thing that this will require is a registered COM server to react to actions when the agent is not running. This requires a unique COM CLSID, which will need to be carefully chosen to allow multiple Firefox installations to coincide.

Just capturing some details: there's a Win32/legacy issue where falling back to the App icon looks horrific: https://github.com/MicrosoftDocs/windows-uwp/issues/1409. It's been closed without being fixed. See also https://stackoverflow.com/q/34965325 which shows the "default" horror, but be aware that the blue backdrop is user specified and could be anything.

It's possible to specify our own image, and https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/adaptive-interactive-toasts#app-logo-override suggests that these should be 48x48. We in fact have that size in the tree already (used for branding on Linux).

Unfortunately our own image changes the visual layout to include an App Identifier string, screenshot to follow.

No longer blocks: 1607833
Depends on: 1607833

Note the "Console WinToast example" string -- that could be whatever we wanted (say, &brandShortName) but would be fixed across all notifications. (I believe it's a property of the App/executable, in this case default-browser-agent.exe.)

(In reply to Nick Alexander :nalexander [he/him] from comment #2)

One technically new thing that this will require is a registered COM server to react to actions when the agent is not running. This requires a unique COM CLSID, which will need to be carefully chosen to allow multiple Firefox installations to coincide.

The approach I am currently taking for this in the BITS service (bug 1515450) is to randomly generate a CLSID, and then point to it with a ProgID based on the path hash (app user model id), something like MozillaBITS6F193CCC56814779.BCM.1. The CLSID can then be retrieved with CLSIDFromProgID by the client or server as long as they know the path hash. We could do this with one of our own registry entries instead, but it seems reasonable to use this builtin indirection mechanism.

Depends on: 1634122

In order to be compatible without our build system, WinToast should use lowercase names for system libraries and should not attempt to build at all on mingw, with which it is not entirely compatible.

Depends on D73951

The Default Browser Agent needs localization, but is external from Firefox. The best option is to do localization the same way the updater does, since it is also external from Firefox. This requires making the tools surrounding updater.ini a bit more generic so they can be reused for the Default Browser Agent.

Depends on D73953

The notifications will need to distinguish among the default browser values detected. I'd rather check against enums than check against string values so the compiler can catch typos.

Depends on D73958

Attachment #9132974 - Attachment is obsolete: true
Attached image notification.png (obsolete) —

The same notification with three times as much text in each field.

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #16)

Created attachment 9146241 [details]
triple_text_notification.png

The same notification with three times as much text in each field.

Unfortunately this looks quite bad. It's basically safe to assume that most of our localizations will get truncated labels for the button.

It seems possible to add a newline to a button by using CR or LF (
 or 
) in the content string, at least in my playing around with Notifications Visualizer. This would be awkward for localization but should at least make it possible to use longer strings. If there's a way to wrap automatically I haven't found it yet.

Attached image notification_on_RTL.PNG

This is the notification displayed with Left-to-Right text on a Right-to-Left operating system (Arabic)

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #18)

It seems possible to add a newline to a button by using CR or LF (
 or 
) in the content string, at least in my playing around with Notifications Visualizer. This would be awkward for localization but should at least make it possible to use longer strings.

Unfortunately I don't think awkward describes the situation accurately. This would be incredibly error prone:

  • Someone needs to test it, and realize that they need a new line. Otherwise they'll ship a button that doesn't make any sense for the user.
  • Add a new line with a format that is not used anywhere else in the codebase (\n is normally used in these case, and that's still confusing).

One the first point, a couple of examples (guessing what German and French could try to use):

  • Italian: Imposta Firefox come browser predefinito… would likely show up as the equivalent of Make Firefox as b
  • German: (guessing) Firefox als Standardbrowser festlegen -> Firefox als Standardbro (Firefox as standardwhat??, no verb)
  • French: (guessin) Faire de Firefox mon navigateur par défaut -> Faire de Firefox mon (Make Firefox my)

That doesn't scale for 96 languages, or even for the ones we care more about, given there's no testing automation (e.g. automated screenshots).

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #19)

Created attachment 9146362 [details]
notification_on_RTL.PNG

This is the notification displayed with Left-to-Right text on a Right-to-Left operating system (Arabic)

Thanks for putting this up here. Confirms my suspicion that we'll need to find a way to set the directionality of the UI. I don't know enough about the underlying windows APIs to suggest how.

Assignee: nalexander → ksteuber

dveditz: it was suggested that the newly imported third-party WinToast library might want sec review and/or fuzzing. (It's the first commit in the attached Phab series, if you'd like to skim yourself.) Looking at the sec review policy at https://wiki.mozilla.org/Security/Reviews/Secure_Development_Lifecycle, it looks much more focused on feature review rather than on the implementation details of third-party code, but can you provide a first pass and redirect us? Thanks!

Flags: needinfo?(dveditz)
Attachment #9145974 - Attachment description: Bug 1621696 - Vendor WinToast library. r?#firefox-build-system-reviewers → Bug 1621696 - Vendor WinToast library. r=froydnj,mhoye
Attachment #9145976 - Attachment description: Bug 1621696 - Fix WinToast to be compatible with our build system r?#firefox-build-system-reviewers → Bug 1621696 - Disable building WinToast on mingw r?#firefox-build-system-reviewers
Attachment #9145977 - Attachment description: Bug 1621696 - Generalize generate_updater_ini.py for more use cases r?#firefox-build-system-reviewers → Bug 1621696 - Generalize generate_updater_ini.py for more use cases r=Pike,froydnj
Attachment #9145978 - Attachment description: Bug 1621696 - Add localization for the default browser agent r=Pike → Bug 1621696 - Add localization for the default browser agent r=Pike,froydnj
Attachment #9146240 - Attachment is obsolete: true
Blocks: 1638055

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:bytesized, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(ksteuber)

Yeah, these patches are waiting for some other work to be ready before they an merge.

Flags: needinfo?(ksteuber)
Attachment #9158641 - Attachment description: Bug 1621696 - Supress the followup notification if the default browser has been changed r=mhowell,agashlin,nalexander → Bug 1621696 - Suppress the followup notification if the default browser has been changed r=mhowell,agashlin,nalexander

Can we file a followup bug blocking mingw-clang to address the WinToast thing? I'm not sure what level of confidentiality is needed/desired here so I don't want to file it wrong.

I'm not entirely sure what you want to be addressed. Do you want this feature to work on mingw?

Flags: needinfo?(tom)

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #28)

I'm not entirely sure what you want to be addressed. Do you want this feature to work on mingw?

I'm guessing that the feature itself is controlled by a pref, right? In that case, we'd like to be compiling all the relevant code and Tor Browser will probably just flip the pref off, but might customize the functionality and use it in the future.

Flags: needinfo?(tom)

I'm guessing that the feature itself is controlled by a pref, right?

There is a pref, and a policy, but this comes with a separate process running as a scheduled task on Windows, set up by the installer / post-update. With the pref off, the task still runs, to check the pref. I'm just guessing, but it seems more likely that Tor Browser would want to configure it disabled at build time.

It's still probably a good idea to have a bug on file for the mingw build failure, though.

Regressions: 1649975
Component: General → Default Browser Agent
Flags: needinfo?(dveditz)
Group: mozilla-employee-confidential
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: