The current state is that we fire error events for content blocking if the error happens synchronously and src was set when the iframe was in-document, or if the error happens asynchronously (from the parent process).
This test is currently setting src before appending the iframe to the document, and thus was expecting no error event to be fired. We have other content security tests that do rely on the error event being fired.
Since we're doing security checks in the parent, the error event now fires, and this changes the test to report success in that case.
Differential Revision: https://phabricator.services.mozilla.com/D75722
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
The current state is that we fire error events for content blocking if the error happens synchronously and src was set when the iframe was in-document, or if the error happens asynchronously (from the parent process).
This test is currently setting src before appending the iframe to the document, and thus was expecting no error event to be fired. We have other content security tests that do rely on the error event being fired.
Since we're doing security checks in the parent, the error event now fires, and this changes the test to report success in that case.
Differential Revision: https://phabricator.services.mozilla.com/D75722
This is mostly changes to handle retrieving the security state asynchronously via the parent process, needing lots of async/await additions.
It also removes the docshell mixed content flag checks (which don't seem to be used in code, only tests), which are mostly still covered by checks of the security UI.
Differential Revision: https://phabricator.services.mozilla.com/D75448
This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
Differential Revision: https://phabricator.services.mozilla.com/D75447
This is mostly changes to handle retrieving the security state asynchronously via the parent process, needing lots of async/await additions.
It also removes the docshell mixed content flag checks (which don't seem to be used in code, only tests), which are mostly still covered by checks of the security UI.
Differential Revision: https://phabricator.services.mozilla.com/D75448
This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
Differential Revision: https://phabricator.services.mozilla.com/D75447
In Tor Browser dom.securecontext.whitelist_onions is true by default, so we need a small
patch for tests from bug 1382359 to pass. We would like to upstream that patch, which
is just making sure dom.securecontext.whitelist_onions is false before starting the test.
Differential Revision: https://phabricator.services.mozilla.com/D76726
This looks like it was necessary a long time ago, but now just runs the same calls as the calling code, so unnecessarily splits the logic into two.
Differential Revision: https://phabricator.services.mozilla.com/D75020
This looks like it was necessary a long time ago, but now just runs the same calls as the calling code, so unnecessarily splits the logic into two.
Depends on D75019
Differential Revision: https://phabricator.services.mozilla.com/D75020
