The refactoring consists of:
- moving tests into dedicated directories for given test type
(browser, mochitest, xpcshell)
- replacing add_test with addTest in browser tests to share common setup code
- adding a way to synchronously load scripts in all test types by providing a
path relative to the top level directory
- adding a way to explicitely run a mochitest inside a worker context
(loadWorkerScript)
- removing the need to declare testGenerator in tests
- removing the need to set some common preferences in individual tests
- sharing common functions for:
- system context (system.js)
- content context (content.js)
- browser tests (browser.js)
- mochitest tests (mochitest.js)
- xpcshell tests (xpcshell.js)
- nested content test inside a browser test (nestedtest.js)
- buffer/view/blob/file (file.js)
Differential Revision: https://phabricator.services.mozilla.com/D73149
This changeset covers the new, severity-based triage process
Fix linting errors
Fix links and language
Fix headings and broken link
Add missing newline to labels.rst
Differential Revision: https://phabricator.services.mozilla.com/D73999
`HTMLEditor` does not remove padding `<br>` element for last empty line when
it becomes unnecessary.
This patch removes it when inserting some text into a text node and it's
followed by a padding <br> element.
Differential Revision: https://phabricator.services.mozilla.com/D74203
This seems to come from bug 618907, which seems to be a hack-around code
that went away in bug 1595435.
If we open a window on mousedown such as it gains focus before this code
runs, we just steal the focus from it, which is undesired.
Also remove the test for bug 799299. It doesn't work anyways if the
browser is remote (this test only runs on non-e10s mode), and this
unifies the behavior with e10s and with content (see attached test-case,
which doesn't change behavior with and without my patch).
Differential Revision: https://phabricator.services.mozilla.com/D73901
Presets used 16Mi entries (128MiB) by default, but these numbers were a limit per process.
Now that the limit is for the whole Firefox app, we would record a lot less information, because there are typically around 8 or more processes.
So the default are now 8 times larger to roughly record a similar amount of profiling data.
Also the custom buffer maximum size has been increased from 1GiB to 2GiB.
Differential Revision: https://phabricator.services.mozilla.com/D73216
These defaults were per process and there are usually around 8 processes.
Now these sizes apply to all processes, so they can be 8 times as big (but less on Android where memory may be more limited.)
Not changing Base Profiler defaults, as its buffer is not cross-process controlled.
Differential Revision: https://phabricator.services.mozilla.com/D73215
Whenever chunks are about to be destroyed, we try to keep one or two alive, to hopefully fulfill the next request, thereby avoiding a deallocation+allocation pair.
Differential Revision: https://phabricator.services.mozilla.com/D72370
This implement the child side:
When the first request for update arrives, it connects to the local chunk manager, to receive its updates.
If multiple updates are received, they are folded into one.
If there are both an update and a pending request, the request is fulfilled with the update and local data is reset.
And ProfilerChild handles "destroy" instructions to destroy local chunks.
At this point, the whole machinery is in place, and all combined profile buffers used in all processes should use around the maximum amount allowed.
A bit more memory may still be used, e.g., due to IPC delays, and because of recycling which keeps some unused chunks alive for later reuse. But overall that should be a small amount compared to the usual user-requested limit.
Differential Revision: https://phabricator.services.mozilla.com/D72369
The logic part of the controller receives all updates, and makes decisions to destroy old chunks when the memory limit is reached.
Differential Revision: https://phabricator.services.mozilla.com/D72368
When there is at least one ProfilerParent (i.e., we are interacting with at least one child process) AND the parent profiler is running, the ProfilerParentTracker sets up the ProfileBufferGlobalController that will manage all chunks.
As a first step, it connects with the local chunk manager (to receive chunk updates), and sends update requests to all children.
(The actual controller logic is not implemented in this patch, nor is the ProfilerChild side, see following patches.)
Differential Revision: https://phabricator.services.mozilla.com/D72367
The Gecko Profiler can notify the ProfilerParent when it's about to stop (if it was started, but the notification will happen even when it's not started).
Differential Revision: https://phabricator.services.mozilla.com/D72365
The Gecko Profiler can provide its current controlled chunk manager.
It is the responsibility of the caller to keep track of the state of the profiler, to avoid using the chunk manager after it's discarded.
Differential Revision: https://phabricator.services.mozilla.com/D72364
The chunk metadata size is tiny (less than 100 bytes) compared to the buffer size (1MB by default), so it's fine to ignore it while dealing with cross-Firefox limits.
Differential Revision: https://phabricator.services.mozilla.com/D72558
Interface class for a chunk manager that can be controlled: It will provide updates about chunks, and release chunks on command.
Differential Revision: https://phabricator.services.mozilla.com/D72362
This code was relying on SessionHistory update having completed when
GlobalHistory is update. Moving GlobalHistory update to the parent process with
DocumentChannel means that it's possible for the GlobalHistory event to fire
before the SessionHistory is updated in nsDocShell.
Switch to using tab loading complete to signal when it's OK to check
SessionHistory.
Differential Revision: https://phabricator.services.mozilla.com/D72280
This value is determined in Parent process and passed down to nsDocShell. Delete
the messages to pass the setting down and set it on the BrowsingContext in the
Parent process.
Refactor the code that determines to opt-out of using global history. Code
inspection determines that windowless browsing contexts want to opt-out as well
as any frame with `disableglobalhistory` attribute set on it.
Differential Revision: https://phabricator.services.mozilla.com/D72279
This is an initial step. In the future it may be nice to avoid loading remote
tabs within windows without `useRemoteTabs` in general.
Differential Revision: https://phabricator.services.mozilla.com/D72936
The element.parentNode.nodeName approach also handled the error, but when I ran the updated model through the training, validation and testing samples, our false positive rate (FPR) went up from 2.2% to 4.5% (referencing the most recent update to NewPasswordModel.jsm in bug 1629132) with a confidence threshold of 0.75. Unfortunately, that is well above our target FPR of 2-3%.
* I am not surprised by this difference: the diff I had tested with `parentNode.nodeName` replaced `parentElement` with `parentNode` and `tagName` with `nodeName` everywhere in this rule. Since `Node.ELEMENT_NODE` is only one of [several other `Node.nodeType`](https://developer.mozilla.org/en-US/docs/Web/API/Node/nodeType)'s, I can imagine that for some of the sites in the corpus, `element.parentElement` was not the same node as `element.parentNode`. Therefore the downstream return value could also be different; i.e. the modified rule may then return `false` instead of `true` or vice versa for some or all of these affected pages, and the model would consequently reach a different (and potentially worse) optimization.
Returning `false` for this rule in these cases will leave the model's performance unchanged on pages that don't use the Shadow DOM at all or in this specific way.
Also add some existence checks further downstream in the same rule where the values could also be `null`.
Differential Revision: https://phabricator.services.mozilla.com/D74164
The second example, when copied and pasted, is completely borked since it
is not preceeded by the line that declares what follows to be a Mermaid
diagram. This change fixes that.
It also fixes the prose to read slightly less awkwardly in places.
Finally, this change also adds a link to the Mermaid Live Editor to make
readers aware of this useful tool.
Differential Revision: https://phabricator.services.mozilla.com/D74338