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
Before the patch, we don't show password manager items when there is no password fields found in a form.
In this patch, we do two things to support a username-only form in the context menu:
1. Add "other" category to fieldname hints. "other" is used for fields that are
in a form but are neither "current-password", "new-password", nor "username".
With the change, the "username" hint is now only used for fields that are considered a username field by the password manager.
2. When there is no password field in a form, ContextMenu also treat a
form as a login form when the active field is a username field, which means it is a username-only form.
Depends on D113796
Differential Revision: https://phabricator.services.mozilla.com/D113797
Before this patch, '_getFormFields' doesn't support forms without password fields.
In this patch, when a form doesn't have a password field, we use the
heuristic added in the previous patch to determine whether the form is a
username-only form. If it is, return the username field.
Depends on D113795
Differential Revision: https://phabricator.services.mozilla.com/D113796
Mostly this moves the code over to a new InternalThreadPool class in a new
source file. The initialization and shutdown code had to change a little
to make this work.
Differential Revision: https://phabricator.services.mozilla.com/D117160
This patch adds a new field to the structures that WER reads from a
crashed process. This field contains a pointer to the global variable
that records the size of the last failed annotation.
When WER intercepts a crash it will use this address to read the
variable. If it's not zero it will add the corresponding annotation
to the crash report.
Depends on D116449
Differential Revision: https://phabricator.services.mozilla.com/D116450
Since this added the new flag to the crash ping I also took the time to update
the crash ping documentation with all the flags that have been added and
removed over the last few versions of Firefox.
Depends on D115380
Differential Revision: https://phabricator.services.mozilla.com/D116017
This also notifies the main process after the minidump has been generated.
I refactored the code a bit so the patch is probably larger than it should be
but the code should be a bit more readable overall.
With this change the minidump generation flow works like this:
- When the callback gets invoked in the WER process we read the structure that
is stored in every process' to figure out if it's the main process or a child
one. This is done by reading said process' memory, the pointer has been
passed to the runtime exception module when it was registered.
- If the main process crashed everything works like it used to.
- If it was a child process then we first capture a minidump of it.
- Then we read the structure representing it in the main process:
WindowsErrorReportingData. The address of this structure was passed into the
child process' command-line so we need to parse that first, then we read it
from the main process memory.
- We fill the structure and write it back into the main process memory.
- At this point if everything went fine we create a new thread in the main
process just to execute the WerNotifyProc function that will inform the main
process to the presence of the new minidump.
There's one important tidbit that's worth keeping in mind: the synchronization
between the main process and the WER process is implicit. The
WindowsErrorReportingData structure in the main process is kept alive until the
child process dies, the main process will destroy it only after that point. As
long as we're in the runtime exception module the crashed process is kept alive
so this will prevent the main process from touching that structure.
We explicitly terminate the crashed process **after** we're done with the
structure so nothing bad could happen... unless someone makes a change to
Gecko that breaks the previous assumption.
Another important thing to keep in mind: we wait for the newly created thread
to inform the main process but only for 5 seconds. We don't want to wait
indefinitely because the function that we're calling is taking a lock and if
it blocks for some reason WER will get stuck waiting for it, so it will never
kill the crashed process which in turn will prevent the main process from
moving ahead. In principle this should never happen but better be safe than
sorry.
Depends on D115379
Differential Revision: https://phabricator.services.mozilla.com/D115380
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
It's a static method and called only with `EditorDOMPointBase` instances.
So, we can add new API to `EditorDOMPointBase` instead.
Note that it's changed to return container when the container is a data node
rather than a text node. This should be better because no data node can
have children.
Depends on D117382
Differential Revision: https://phabricator.services.mozilla.com/D117490
