When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
When the tracking protection toast popup closes on a timer, it doesn't
smoothly fade out, because it uses PanelMultiView.hidePopup instead of
panelNode.hidePopup. The static method on PanelMultiView ultimately
calls panelNode.hidePopup, but it doesn't have a parameter for enabling
the animation so it passes nothing to that method. This patch extends
PanelMultiView's hidePopup class methods to add an optional `animate`
parameter, and adds that parameter to the toast popup's hidePopup call.
This should slightly reduce the speed of part of
browser_protectionsUI.js but I don't think it affects any other tests.
Differential Revision: https://phabricator.services.mozilla.com/D146394
- Adding browser tests to verify correct behavior in integration
- New test that fails on previous version: toolkit/components/antitracking/test/browser/browser_storageAccessScopeSameSiteWrite.js
- Add the ability to store permission by site, use 3rdPartyStorage for this
- No change is made to permission reads. These already proceed recursively, which eventually reach the site.
- When fetching all permissions for a principal, also look for site-scoped permissions on its site's principal
Differential Revision: https://phabricator.services.mozilla.com/D130675
- Adding browser tests to verify correct behavior in integration
- New test that fails on previous version: toolkit/components/antitracking/test/browser/browser_storageAccessScopeSameSiteWrite.js
- Add the ability to store permission by site, use 3rdPartyStorage for this
- No change is made to permission reads. These already proceed recursively, which eventually reach the site.
- When fetching all permissions for a principal, also look for site-scoped permissions on its site's principal
Differential Revision: https://phabricator.services.mozilla.com/D130675
* Updates the addressbar "lock" icon for the tracking-protection blocked/disabled state, the default "no trackers" state, and the "trackers blocked" state. Where we used to animate the transition to trackers blocked, its now a static iconwith the same blue/purple gradient fill.
* Remove browser_protectionsUI_animation.js which was specifically testing the animation behavior and use of the animation frames as visible icons, which is no longer the case
* Rename and adjust browser_protectionsUI_animation_2.js which is primarily testing the active/not state of the icon
Differential Revision: https://phabricator.services.mozilla.com/D111507
Updates the addressbar "lock" icon for the tracking-protection blocked/disabled state, the default "no trackers" state, and the "trackers blocked" state. Where we used to animate the transition to trackers blocked, its now a static iconwith the same blue/purple gradient fill.
Differential Revision: https://phabricator.services.mozilla.com/D111507
- Added a new permission panel managed by the gPermissionPanel object
- Updated identity-box to separate identity and permission section
Differential Revision: https://phabricator.services.mozilla.com/D99892
- Added a new permission panel managed by the gPermissionPanel object
- Updated identity-box to separate identity and permission section
Differential Revision: https://phabricator.services.mozilla.com/D99892
- Added a new permission panel managed by the gPermissionPanel object
- Updated identity-box to separate identity and permission section
Differential Revision: https://phabricator.services.mozilla.com/D99892
This also only updates per-category block information in the protections panel
while it's open or when it's about to be shown. To do this, the patch:
1. changes the `categoryItem` getter on all blockers to avoid memo'izing null when the popup is unavailable;
2. changes the `updateCategoryItem` method on all blockers to deal with `categoryItem` being null;
3. stops calling `updateCategoryItem` from the blockers' `init` method, instead delegating this responsibility
to gProtectionsHandler doing so when the popup first becomes available. Note that we still need (2) because
pref changes can trip us calling into `updateCategoryItem` anyway. We cannot avoid instantiating the pref
getters because they are relied on by some of the `isDetected` and `isBlocking` implementations.
4. reorganizes `onContentBlockingEvent` so it updates the icon, reports telemetry, and updates internal state -
but only updates the panel if it's visible, and otherwise simply memorizes the last event (which is just
a number!);
5. ensures showing the panel updates the panel's category data based on the memorized state from (4).
Differential Revision: https://phabricator.services.mozilla.com/D81926
This also only updates per-category block information in the protections panel
while it's open or when it's about to be shown. To do this, the patch:
1. changes the `categoryItem` getter on all blockers to avoid memo'izing null when the popup is unavailable;
2. changes the `updateCategoryItem` method on all blockers to deal with `categoryItem` being null;
3. stops calling `updateCategoryItem` from the blockers' `init` method, instead delegating this responsibility
to gProtectionsHandler doing so when the popup first becomes available. Note that we still need (2) because
pref changes can trip us calling into `updateCategoryItem` anyway. We cannot avoid instantiating the pref
getters because they are relied on by some of the `isDetected` and `isBlocking` implementations.
4. reorganizes `onContentBlockingEvent` so it updates the icon, reports telemetry, and updates internal state -
but only updates the panel if it's visible, and otherwise simply memorizes the last event (which is just
a number!);
5. ensures showing the panel updates the panel's category data based on the memorized state from (4).
Differential Revision: https://phabricator.services.mozilla.com/D81926
This also only updates per-category block information in the protections panel
while it's open or when it's about to be shown. To do this, the patch:
1. changes the `categoryItem` getter on all blockers to avoid memo'izing null when the popup is unavailable;
2. changes the `updateCategoryItem` method on all blockers to deal with `categoryItem` being null;
3. stops calling `updateCategoryItem` from the blockers' `init` method, instead delegating this responsibility
to gProtectionsHandler doing so when the popup first becomes available. Note that we still need (2) because
pref changes can trip us calling into `updateCategoryItem` anyway. We cannot avoid instantiating the pref
getters because they are relied on by some of the `isDetected` and `isBlocking` implementations.
4. reorganizes `onContentBlockingEvent` so it updates the icon, reports telemetry, and updates internal state -
but only updates the panel if it's visible, and otherwise simply memorizes the last event (which is just
a number!);
5. ensures showing the panel updates the panel's category data based on the memorized state from (4).
Differential Revision: https://phabricator.services.mozilla.com/D81926
