Ensure that `bookmark-item` and `history-item` scalars are updated when the corresponding links are opened in new tab/window via context menu.
Differential Revision: https://phabricator.services.mozilla.com/D174904
We can't add the provenance data to the `installation.first_seen` extra data because it is already at its maximum number of keys. So instead we will add the `installation.first_seen_prov_ext` event which will be sent at the same time as `installation.first_seen` and will contain provenance attribution data in its extras object.
Differential Revision: https://phabricator.services.mozilla.com/D172520
nsIPermissionManager already keys by principal origin so updating SitePermissions to do the same will make our
permission handling more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D167988
This adds probes and a limited set of tests for the following types of measurements:
1. A count for each time the All Tabs panel is opened, keyed on the entrypoint.
2. A count for each usage of the Tab Context Menu, keyed on the trigger node
as the entrypoint.
3. A count for each dragstart within the All Tabs panel.
Differential Revision: https://phabricator.services.mozilla.com/D168305
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
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
