Windows Default Browser Agent - Phase 2 - Windows 10 toast notification API integration
Categories
(Toolkit :: Default Browser Agent, enhancement)
Tracking
()
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.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 2•5 years ago
|
||
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.
Reporter | ||
Comment 3•5 years ago
|
||
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.
Reporter | ||
Comment 4•5 years ago
|
||
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
.)
Comment 5•5 years ago
|
||
(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.
Assignee | ||
Comment 6•5 years ago
|
||
The WinToast library is licensed MIT.
This version was vendored via:
wget https://raw.githubusercontent.com/mohabouje/WinToast/09227c72f16ccefc36e9d430dea3b435346dbcbc/LICENSE.txt
wget https://raw.githubusercontent.com/mohabouje/WinToast/09227c72f16ccefc36e9d430dea3b435346dbcbc/src/wintoastlib.cpp
wget https://raw.githubusercontent.com/mohabouje/WinToast/09227c72f16ccefc36e9d430dea3b435346dbcbc/src/wintoastlib.h
Assignee | ||
Comment 7•5 years ago
|
||
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
Assignee | ||
Comment 8•5 years ago
|
||
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
Assignee | ||
Comment 9•5 years ago
|
||
Depends on D73954
Assignee | ||
Comment 10•5 years ago
|
||
Depends on D73955
Assignee | ||
Comment 11•5 years ago
|
||
Depends on D73956
Assignee | ||
Comment 12•5 years ago
|
||
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
Assignee | ||
Comment 13•5 years ago
|
||
Depends on D73960
Assignee | ||
Comment 14•5 years ago
|
||
Depends on D73962
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 15•5 years ago
|
||
Assignee | ||
Comment 16•5 years ago
|
||
The same notification with three times as much text in each field.
Comment 17•5 years ago
|
||
(In reply to Kirk Steuber (he/him) [:bytesized] from comment #16)
Created attachment 9146241 [details]
triple_text_notification.pngThe 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.
Comment 18•5 years ago
|
||
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.
Assignee | ||
Comment 19•5 years ago
|
||
This is the notification displayed with Left-to-Right text on a Right-to-Left operating system (Arabic)
Comment 20•5 years ago
•
|
||
(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 ofMake 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).
Comment 21•5 years ago
|
||
(In reply to Kirk Steuber (he/him) [:bytesized] from comment #19)
Created attachment 9146362 [details]
notification_on_RTL.PNGThis 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 | ||
Updated•5 years ago
|
Reporter | ||
Comment 22•5 years ago
|
||
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!
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 23•5 years ago
|
||
Comment 24•5 years ago
|
||
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.
Assignee | ||
Comment 25•5 years ago
|
||
Yeah, these patches are waiting for some other work to be ready before they an merge.
Assignee | ||
Comment 26•5 years ago
|
||
Updated•5 years ago
|
Comment 27•5 years ago
|
||
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.
Assignee | ||
Comment 28•5 years ago
|
||
I'm not entirely sure what you want to be addressed. Do you want this feature to work on mingw?
Comment 29•5 years ago
|
||
(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.
Comment 30•5 years ago
|
||
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.
Comment 31•5 years ago
|
||
Merged to central:
https://hg.mozilla.org/mozilla-central/rev/15e6e5554039f45271222226c58215eaff725257
https://hg.mozilla.org/mozilla-central/rev/570afd3a9fe9af6d9f84a9df272cfc688caf6bf9
https://hg.mozilla.org/mozilla-central/rev/ad51b2d2eedd21924b4bb65d993948cfebe622d7
https://hg.mozilla.org/mozilla-central/rev/01b470cc5910c308fc708641572f5900d9f7b067
https://hg.mozilla.org/mozilla-central/rev/e60871c6c19241feebc75f3c5b4090d2fd944ce9
https://hg.mozilla.org/mozilla-central/rev/578b28bc04ea6ebbad2f42dd815cb81ca4189c86
https://hg.mozilla.org/mozilla-central/rev/66711d6a17b2c68943280c01e6a4d54525fd60d4
https://hg.mozilla.org/mozilla-central/rev/e8e6884a16b295971e48d8d9c922eeb366cc3e68
https://hg.mozilla.org/mozilla-central/rev/d573712ab88e95aad88e605a3095c6ede40db9fb
https://hg.mozilla.org/mozilla-central/rev/392bc8ad6fea1953416105d7b594236ed5b87527
![]() |
||
Comment 32•5 years ago
|
||
https://hg.mozilla.org/integration/autoland/rev/15e6e5554039f45271222226c58215eaff725257
https://hg.mozilla.org/integration/autoland/rev/570afd3a9fe9af6d9f84a9df272cfc688caf6bf9
https://hg.mozilla.org/integration/autoland/rev/ad51b2d2eedd21924b4bb65d993948cfebe622d7
https://hg.mozilla.org/integration/autoland/rev/01b470cc5910c308fc708641572f5900d9f7b067
https://hg.mozilla.org/integration/autoland/rev/e60871c6c19241feebc75f3c5b4090d2fd944ce9
https://hg.mozilla.org/integration/autoland/rev/578b28bc04ea6ebbad2f42dd815cb81ca4189c86
https://hg.mozilla.org/integration/autoland/rev/66711d6a17b2c68943280c01e6a4d54525fd60d4
https://hg.mozilla.org/integration/autoland/rev/e8e6884a16b295971e48d8d9c922eeb366cc3e68
https://hg.mozilla.org/integration/autoland/rev/d573712ab88e95aad88e605a3095c6ede40db9fb
https://hg.mozilla.org/integration/autoland/rev/392bc8ad6fea1953416105d7b594236ed5b87527
Assignee | ||
Updated•3 years ago
|
Updated•1 year ago
|
Updated•3 months ago
|
Description
•