As for document.fonts, I don't think we intentionally meant to apply
CSP to User/UserAgent fonts. The document certainly has no authority
to block those from loading. (We already have a separate principal
for these which is further evidence that this was unintentional
and we can use the same bit (mUseOriginPrincipal) to avoid CSP.)
Differential Revision: https://phabricator.services.mozilla.com/D111695
Per https://github.com/w3c/csswg-drafts/issues/6126 these were
never intended to be included in the first place so this is just
fixing a bug. Note that I'm leaving them in the mRuleFaces array
so that the font loading machinery works the same as before.
I'm just excluding them when queried by document.fonts.
Differential Revision: https://phabricator.services.mozilla.com/D111694
Specifically:
For "bullets", i.e. 'list-style-type:disc|circle|square|
disclosure-closed|disclosure-open', we use a built-in font
(-moz-bullet-font, which has glyphs for those symbols + space) to
retain mostly backwards compatible rendering for those. Authors may
override that with an explicit 'font-family' ::marker style though.
We also use this font for 'list-style-image' in case it would
fallback to one of the above when the image fails to load (so that
we get the same width space).
When the -moz-bullet-font is used we also set 'font-synthesis' to
avoid synthesizing italic/bold for this font. Authors may override
this with an explicit ::marker declaration.
We also set 'letter-spacing' and 'word-spacing' to the initial value
for bullets for web-compat reasons. Again, authors may override
this with an explicit ::marker declaration. (This breaks backwards-
compat slightly but makes us compatible with Chrome. We used to
ignore these for list-style-type:<string> too.)
Differential Revision: https://phabricator.services.mozilla.com/D111693
The public key pinning implementation is much less complex than the HSTS
implementation, and only needs a small subset of the parameters of the latter.
Furthermore, the information it relies on is static, and so is safe to access
from content processes. This patch separates the two implementations, thus
simplifying both of them and avoiding some unnecessary IPC calls in the
process.
Differential Revision: https://phabricator.services.mozilla.com/D117096
This patch converts the pinning preference
"security.cert_pinning.enforcement_level" to be static. It also removes some
unused pinning preferences and parameters.
Differential Revision: https://phabricator.services.mozilla.com/D117095
Previously, SetDisableAllSecurityChecksAndLetAttackersInterceptMyData would
only work as expected if another operation happened to clear the TLS session
cache (namely, changing a preference that caused nsNSSComponent to change its
TLS options and clear the TLS session cache). This patch ensures that this
function works without relying on such coincidences.
Differential Revision: https://phabricator.services.mozilla.com/D117495
In the former case (for browser_modal_print.js), the test-failures seem to just
be bug 1700803, a known intermittent that's not asan/fission-specific (though
it might be worse with fission -- we can keep an eye on failure rates to see).
In the latter case (for browser_print_in_container.js), it looks like the test
has some known intermittent timeouts on slow configurations, and it's had some
observed timeouts on **non-fission** Linux-ASAN runs. So it seems likely that
our Linux+ASAN+fission annotation there was accidentally too-specific, and
fission probably wasn't a relevant subcondition there. Therefore, this patch
is just removing fission from that condition, so the test will now be skipped on
Linux ASAN testruns in general.
Differential Revision: https://phabricator.services.mozilla.com/D117363
This patch adds the ability to build conditioned profiles during a test (i.e. in-test, prebuilt, or in-task for CI). Using the `artifact:` prefix in --conditioned-profile will cause the conditioned profile to be downloaded from mozilla-central rather than being built locally.
The condprof package was also modified to prevent it from building and saving logs that are not very useful in local runs, preventing useless downloads or archiving, and to also be able to obtain the location of the test-built profile.
Differential Revision: https://phabricator.services.mozilla.com/D116520
Reject software rasterizers on Linux (except Software WebRender) when
trying to create full WebRender, unless WebRender was force enabled.
Differential Revision: https://phabricator.services.mozilla.com/D117534
When trying to create a GLContextEGL or GLContextGLX, we should check to
see what our display is backed by. If using a software driver, we should
fail to create the context for WebRender, so that it can fallback to
Software WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D117473
This patch adds two telemetry to measure the performance impact after adding
multi-page login support.
Telemtry PWMGR_IS_USERNAME_ONLY_FORM gives us an idea among
all forms that contain a possible username input (type is email or text), the propotion
of those forms that are considered as a username-only form by our heuristic. We can
use this data as a hint of whether the username-only form heuristic works properly.
Telemetry PWMGR_NUM_FORM_HAS_POSSIBLE_USERNAME_EVENT_PER_DOC gives us an
idea how many forms contain a possible username input per page. If the data shows that there are a
lot of pages that contain multiple forms with a possible username input, which
triggers the new code path added in this bug, we might need to pay more attention to see whether the
change introduces performance overhead for page load.
Ex. A doc has 4 forms
<form><input type=email autocomplete=username/></form> <!-- This is a form with a possible username input, and it is a username-only form-->
<form><input type=text autocomplete=username/></form> <!-- This is a form with a possible username input, and it is a username-only form-->
<form><input type=email/></form> <!-- This is a form with a possible username input, but it is NOT a username-onlyc form -->
<form><input type=urk/></form> <!-- This is a form WITHOUT a possible username input -->
PWMGR_IS_USERNAME_ONLY_FORM records
bucket[0] = 1 // 1 form with a possible username input but not a username-only form
bucket[1] = 2 // 2 forms are username-only form.
PWMGR_NUM_FORM_HAS_POSSIBLE_USERNAME_EVENT_PER_DOC records
bucket[0] = 0
bucket[1] = 1 // 1 doc has 1 or more than 1 form with a possible-username input
bucket[2] = 1 // 1 doc has 2 or more than 2 form with a possible-username input
bucket[3] = 1 // 1 doc has 3 or more than 3 form with a possible-username input
bucket[4] = 0 // 0 doc has 4 or more than 4 form with a possible-username input
Depends on D113802
Differential Revision: https://phabricator.services.mozilla.com/D116237
This patch saves the username field in a username-only form when the form is submitted.
When another form in the same document is submitted after that, if the form doesn't
have a username field, we then use the username field found in the username-only form to capture login.
This fits the case that in a multipage sign-in form, the first form is
usually a username-only form and the second form is usually a password-only form.
However, in the current approach, if in the second form, there is an input field before the
password field, we will use the input field in the second form as the username field, not the username field
in the first form. For example, in a multipage registration form, the first form is a username-only form to
enter your email, and the second form has an input field to enter the last name and a password field. With the
current approach, we will save "last name" + "password" instead of "username" + "password".
An alternate is always using the username field in the first form or coming up with a heuristic
to "compare" the two username fields. But since I haven't found a real-world example of the above scenario,
using the current approach seems a safer way to introduce the feature.
Depends on D113800
Differential Revision: https://phabricator.services.mozilla.com/D113801
In the previous patch to support autofill, a username field in a
username-only form is marked as a login manager field in '_fillForm'.
So this patch only makes autocomplete highlight work when autocomplete a username field.
This patch calls '_highlightFilledField' in 'onUsernameAutoCompleted'
when the autocompleted field is the username field in a username-only
form.
This is because when we autocomplete a username field in a form with password fields,
the highlight is done in '_fillForm'. However, in the case of a username-only
form, we don't have to call '_fillForm' anymore due to no password to fill.
Depends on D113799
Differential Revision: https://phabricator.services.mozilla.com/D113800
This patch does two things:
1. Checks whether a form is a username-only form after receiving 'DOMFormHasPossibleUsername' event.
If it is, fetch logins from the parent to trigger form autofill.
2. Makes LoginManagerChild._fillForm compatible with an empty password field when there is an username field.
Depends on D113798
Differential Revision: https://phabricator.services.mozilla.com/D113799
Right now, we limit the type of a username field in username-only forms to be either text or email.
This is different from what the password manager currently support in LoginHelper.isUsernameFieldType.
This is because text and email type are the most common cases for a username field, and we want to focus
on the cases that are more likely a username field.
This patch adds "DOMFormHasPossibleUsername" event to notify the password manager when a form has a possible
username field (text or email). The event works similar to the existing "DOMFormHasPassword" event.
Depends on D113797
Differential Revision: https://phabricator.services.mozilla.com/D113798
Mats Palmgren
Butkovits Atila
Daniel Holbert
Dana Keeler
Gavin Lazar Suntop
Emilio Cobos Álvarez
Nicolas Chevobbe
Gregory Mierzwinski
Dorel Luca
Julian Descottes
Nicolas Silva
Andrew Osmond
Frederik Braun
Christoph Kerschbaumer
Dimi Lee