... because these URIs are incompatible with TP.
We now show it on moz-extension: instead, which was forgotten previously.
This should probably have been in its own separate bug, but the changes in bug 1470020
surfaced this issue by throwing a lot of console errors when the baseURI was accessed,
so I didn't want to defer the fix.
MozReview-Commit-ID: 8KNV0oabv7Y
We used to give this all the same "tracking-loaded" state, but now we want to differentiate between:
- Tracking loaded because TP is off
- Tracking loaded because of an exception
- Tracking not loaded but the site has an exception, which we want to allow the user to remove (if TP is on)
MozReview-Commit-ID: E9j0Roq1bsH
Part 2 exposed an edge case that would allow the user to have TP enabled but
still have tracking content on a page, bringing our UI into a confused state.
This adds a new element that shows when TP is enabled and no exception is set,
but tracking content is still loaded, and recommends reloading the page.
MozReview-Commit-ID: EYy6xVCjNts
This commit changes the tracking protection UI to always be present in the
identity popup (control center) UI. Following the UI spec in
https://mozilla.invisionapp.com/share/RSIY1B8GMC2#/screens/297824891,
we are now warning about trackers even when TP is disabled and alter the
button that shows up in this case to open the TP settings in about:preferences.
MozReview-Commit-ID: 6g8rzWVRaua
This implements a new button in the identity popup that allows users to quickly
remove cookies and site data from the sites they're visiting.
This uses the SiteDataManager behind the scenes and is similar to the changes
we made for PageInfo already.
There's a major drawback to this approach in that SiteDataManager needs to
refresh its entire data set everytime we want information about a single site
or want to remove anything (it's not trivial to get rid of that limitation while
dealing with all the quirks of our storage APIs). I will work around this by
implementing a way for SiteDataManager to incrementally update itself in bug 1460768.
MozReview-Commit-ID: Iy7ia0KllFq
The site security subview is now implemented using the "photonpanelmultiview" element, replacing the last instance of the "panelmultiview" element. The subview features a standard Photon header, hence the connection state icon was moved to the element below it. This makes the styles more similar between the main view and the subview. The connection state styles are now applied using a class name, and the tests have been updated accordingly.
This change required some fixes in the "photonpanelmultiview" implementation to make sure the height of the subview is correct and to allow keyboard navigation back to the main view.
Since the expander button and the permission controls in the main view are not visible anymore after the subview is shown, some code related to focus and hover could be removed as well.
MozReview-Commit-ID: 4nIAPWJPV8k
The height of the "panelmultiview" binding is now determined by the stack layout code, and doesn't have to be calculated manually via JavaScript anymore. This allows the removal of mutation and overflow observers, and reduces the number of synchronous layouts being made.
There is still a workaround included for wrapping blocks not being taken into account in height calculations.
MozReview-Commit-ID: 9rrPU5O5hUx
