Unify the values of "source" and "page" as used in FeatureCallout.sys.mjs:
- Explicitly pass in a value for "page" when instantiating a Feature Callout and use this for the value of "page" when sending Feature Callout telemetry and as the "source" when making calls to `sendTriggerMessage`. This avoids the risk of including non-about: page URLs or PDF file extensions in our telemetry.
- Set the value of "page" in an HTML data attribute that can be accessed for use in about:welcome telemetry for Spotlight and Feature Callouts.
- Update references to the page value previously used as the page/source for telemetry from `about:firefoxview` Feature Callouts from "firefoxview" to "about:firefoxview"
- Pass the token "chrome" when creating a callout from the browser chrome and update references to the source in PDF.js messages' targeting
- Update the page value expected in automated tests as needed
Differential Revision: https://phabricator.services.mozilla.com/D165910
This is the bare minimum that's reasonable to do -- it gives us a simple test of the happy path. The diff is largely indentation changes.
Differential Revision: https://phabricator.services.mozilla.com/D166687
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
An all-device "Allow" option is not provided because the permission grant
prompt is primarily a device selection, which will (with subsequent patches)
grant persistent permission for the selected device.
Bug 1800287 covers setting a similar block from the selectAudioOutput() prompt.
Differential Revision: https://phabricator.services.mozilla.com/D162232
Makes passing a progress object as part of options more coherent in the
Sanitizer, so we don't need to null check it everywhere.
Create a sub progress object for each cleaner, so they don't overwrite each
other reusing the same property names (like "step"), since all the cleaners are
started in parallel.
Add a few steps to the history cleaner.
This also fixes a typo in the openWindows cleaner, that should receive an object
rather than a string as second argument. Adding a test for this feature is not
trivial, thus I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1803174.
Differential Revision: https://phabricator.services.mozilla.com/D163352
This creates a new service that stores precisely two bits per RP, IDP, and account ID tuple:
has it been used before and is it able to be logged out.
It does so with the additional constraints of respecting private browsing's clear on last session and in-memory storage constraints and being a participant in the Clear Storage Service.
Tests are here. Coverage isn't perfect, but they cover most of the service.
Differential Revision: https://phabricator.services.mozilla.com/D162124
This creates a new service that stores precisely two bits per RP, IDP, and account ID tuple:
has it been used before and is it able to be logged out.
It does so with the additional constraints of respecting private browsing's clear on last session and in-memory storage constraints and being a participant in the Clear Storage Service.
Tests are here. Coverage isn't perfect, but they cover most of the service.
Differential Revision: https://phabricator.services.mozilla.com/D162124
This creates a new service that stores precisely two bits per RP, IDP, and account ID tuple:
has it been used before and is it able to be logged out.
It does so with the additional constraints of respecting private browsing's clear on last session and in-memory storage constraints and being a participant in the Clear Storage Service.
Tests are here. Coverage isn't perfect, but they cover most of the service.
Differential Revision: https://phabricator.services.mozilla.com/D162124
This creates a new service that stores precisely two bits per RP, IDP, and account ID tuple:
has it been used before and is it able to be logged out.
It does so with the additional constraints of respecting private browsing's clear on last session and in-memory storage constraints and being a participant in the Clear Storage Service.
Tests are here. Coverage isn't perfect, but they cover most of the service.
Differential Revision: https://phabricator.services.mozilla.com/D162124
Ideally we would use the window mediator to just find new browser windows that
are in the process of opening but while we can find the windows they just appear
as about:blank with no way to verify that they are browser windows.
This just takes the straightforward approach of forcing code that opens browser
windows to register them with the BrowserWindowTracker and provides a simple
shared API for opening browser windows that does this.
Differential Revision: https://phabricator.services.mozilla.com/D161076
