Add a document.addCertException function to about:certerror pages, and use it on the desktop certerror page.
Also, as the CallerIsTrusted* functions expect URLs like about:certerror, but GeckoView error pages are data URLs, and so need to be handled differently for these special error-page methods to be exposed on their documents.
Example usage of document.addCertException:
document.addCertException(
true|false /* true == temporary, false == permanent */
).then(
() => {
location.reload();
},
err => {
console.error(err);
}
);
Differential Revision: https://phabricator.services.mozilla.com/D56974
Add a document.addCertException function to about:certerror pages, and use it on the desktop certerror page.
Also, as the CallerIsTrusted* functions expect URLs like about:certerror, but GeckoView error pages are data URLs, and so need to be handled differently for these special error-page methods to be exposed on their documents.
Example usage of document.addCertException:
document.addCertException(
true|false /* true == temporary, false == permanent */
).then(
() => {
location.reload();
},
err => {
console.error(err);
}
);
Differential Revision: https://phabricator.services.mozilla.com/D56974
As it turns out, there are some sites that generate this error. It's a small
number, but enough to justify the change.
No new tests because we can't generate this condition in our test setup.
Differential Revision: https://phabricator.services.mozilla.com/D50396
BrowserTestUtils.waitForErrorPage may resolve slightly earlier than it did
before, so we may arrive at an about:neterror page that hasn't been completely
initialized. We should only dispatch the AboutNetErrorLoad event when we're done
making changes to the page.
Differential Revision: https://phabricator.services.mozilla.com/D51439
BrowserTestUtils.waitForErrorPage may resolve slightly earlier than it did
before, so we may arrive at an about:neterror page that hasn't been completely
initialized. We should only dispatch the AboutNetErrorLoad event when we're done
making changes to the page.
Differential Revision: https://phabricator.services.mozilla.com/D51439
BrowserTestUtils.waitForErrorPage may resolve slightly earlier than it did
before, so we may arrive at an about:neterror page that hasn't been completely
initialized. We should only dispatch the AboutNetErrorLoad event when we're done
making changes to the page.
Differential Revision: https://phabricator.services.mozilla.com/D51439
As it turns out, there are some sites that generate this error. It's a small
number, but enough to justify the change.
No new tests because we can't generate this condition in our test setup.
Differential Revision: https://phabricator.services.mozilla.com/D50396
document.l10n.formatValues seems to have changed and now not throw an error but instead
return `undefined` when no string was found. This broke the implementation which relied
on try..catch to detect non-existent error strings.
Differential Revision: https://phabricator.services.mozilla.com/D49873
As we roll out the TLS 1.0 and 1.1 deprecation, sites that don't support TLS 1.2
will show the neterror page. This adds a box to that page that shows in this
specific case. That box explains what is going on and gives an option to
re-enable TLS 1.0.
As mentioned, this will show alongside an option to reset TLS-related
preferences if any overrides are active.
Hitting the button will set the new pref to 'true' and reload the page.
Once the override is engaged, the option won't show, but that option to reset
preferences will show (as this is a TLS-related preference).
The intent is to remove this affordance in March 2020 as we formally move to
having TLS 1.2 the minimum version. All going to plan, this will only affect
prerelease channels, though anyone who has tweaked security.tls.version.* could
also see this.
Differential Revision: https://phabricator.services.mozilla.com/D45799
As we roll out the TLS 1.0 and 1.1 deprecation, sites that don't support TLS 1.2
will show the neterror page. This adds a box to that page that shows in this
specific case. That box explains what is going on and gives an option to
re-enable TLS 1.0.
As mentioned, this will show alongside an option to reset TLS-related
preferences if any overrides are active.
Hitting the button will set the new pref to 'true' and reload the page.
Once the override is engaged, the option won't show, but that option to reset
preferences will show (as this is a TLS-related preference).
The intent is to remove this affordance in March 2020 as we formally move to
having TLS 1.2 the minimum version. All going to plan, this will only affect
prerelease channels, though anyone who has tweaked security.tls.version.* could
also see this.
Differential Revision: https://phabricator.services.mozilla.com/D45799
We were using the same ID on two elements, which kind of messed up things everywhere
our code reasonably expected only one element of the kind to exist. We just use a
class name now.
This also cleans up #advancedPanelErrorTryAgain which worked around this issue
by using a different ID.
Differential Revision: https://phabricator.services.mozilla.com/D30298
The larger changesets in this patch are simply moving code from one file into the other with hg mv.
A short summary of the changes:
- I removed the forked redirection from AboutRedirector.cpp
- I deleted the original aboutNetError.xhtml and aboutNetError.css files
and moved aboutNetError-new.xhtml and aboutNetError-new.css in their place instead.
- I removed the browser.security.newcerterrorpage.enabled pref and all its usages.
- I removed some localization strings and resources that went unused because of the above changes.
Differential Revision: https://phabricator.services.mozilla.com/D25232
