This patch has a few minor improvements to `./mach ide vscode` to make
it nicer to use in various situations. Specifically:
* Tries to locate the `code` using `shutil.which` in addition to the
existing methods so that the binary is found when being run from
within a vscode remote shell.
* If locating the code binary fails, only prompts to ask whether or not
to continue, rather than requiring entering the complete path. The
only use of the vscode command is to start an instance connected to the
correct path, so if no binary was found, a message is logged instead.
(bug 1699943)
* When changes need to be made to the settings.json file, a full diff is
shown between the old and new files, rather than just showing the
computed state before and after.
* If parsing the existing settings.json file fails (e.g. because there
were c-style comments in it - see bug 1670997), the diff is shown and
an additional warning is emitted to ask if the change should be made.
Differential Revision: https://phabricator.services.mozilla.com/D121157
Chrome has removed 3DES completely[0], but we're still seeing some uses of it
in telemetry. Our assumption is that this is either due to old devices that
can't be upgraded, and hence probably use TLS 1.0, or servers that bafflingly
choose 3DES when there are other, better, ciphersuites in common.
This patch allows 3DES to only be enabled when deprecated versions of TLS are
enabled. This should protect users against the latter case (where 3DES is
unnecessary) while allowing them to use it in the former case (where it may be
necessary).
NB: The only 3DES ciphersuite gecko makes possible to enable is
TLS_RSA_WITH_3DES_EDE_CBC_SHA. This patch also changes the preference
corresponding to this ciphersuite from "security.ssl3.rsa_des_ede3_sha" to
"security.ssl3.deprecated.rsa_des_ede3_sha".
[0] https://www.chromestatus.com/feature/6678134168485888
Differential Revision: https://phabricator.services.mozilla.com/D121797
Correct the description of the MacMemoryPressureSysctl crash annotation to indicate 1 is the value for normal memory pressure.
The integer values are from the XNU kernel event.h header file and observable with `$ sysctl kern.memorystatus_vm_pressure_level`.
Differential Revision: https://phabricator.services.mozilla.com/D122032
This patch upgrades the kinto-http.js library to add a `fetchFunc` hook.
We then replace calls to `fetch()` everywhere by `Utils.fetch()` which will leverage ServiceRequest, a derivative of XMLHTTPRequest that sets the beConservative flag.
Differential Revision: https://phabricator.services.mozilla.com/D121531
This enables us to use CDMs that support multiple key systems. E.g. if we have a
CDM that supports keySystem1 and keySystem2, and it needs to know which key
system we want, this lets us tell it which.
This exact case can be used to let us have a more flexible and configurable
clearkey CDM with differently behaved key systems for specific tests.
Differential Revision: https://phabricator.services.mozilla.com/D122137
Right now, GetCDM is only called with aTags containing a key system string. This
patch changes the function args to reflect that. This makes it easier to reason
about the function without having to look up call sites.
Differential Revision: https://phabricator.services.mozilla.com/D122136
And make sure the caret ends up being visible, rather than _not_
visible.
This should be implementable on windows as well. It seems macOS doesn't
have a timeout thing.
Differential Revision: https://phabricator.services.mozilla.com/D122132
Without this change, there was a race where the promiseBrowserLoaded promise
from the loadURL call could return early due to observing the load completing
for the default about:blank document, rather than for the second explicit
about:blank load, leading to intermittent timeouts due to loads interrupting
one-another. This change skips the default about:blank document load with
nodefaultsrc, avoiding the issue.
Differential Revision: https://phabricator.services.mozilla.com/D121778
This change makes all browsers which were not created with an initial `remote`
attribute within a non-`useRemoteTabs` window be unable to process-switch, as
otherwise we may attempt to switch loads into a content process. We need to
keep process switching enabled for explicitly-remote browsers loaded in a
non-`useRemoteTabs` window as it's relied on for tests and can lead to
assertion failures due to loading remote content in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D121285
This load was causing a process switch after the changes in this patch.
This caused the view-source load to also process-switch back when loaded
and confused some view-source machinery. The load isn't necessary, and
if skipped the process switch due to navigation will not occur.
Differential Revision: https://phabricator.services.mozilla.com/D120736
The changes in the previous part had a few behaviour changes which are visible
in tests, including cross-origin iframes with sandboxed origins now loading
remotely, and process selection for chrome-triggered null principal loads
behaving differently. In general this caused more process switches.
Differential Revision: https://phabricator.services.mozilla.com/D120674
This is a large refactoring of the DocumentChannel process switch codepath,
with the end goal of being better able to support future process switch
requirements such as dynamic isolation on android, as well as the immediate
requirement of null principal handling.
The major changes include:
1. The logic is in C++ and has less failure cases, meaning it should be harder
for us to error out unexpectedly and not process switch.
2. Process selection decisions are more explicit, and tend to rely less on
state such as the current remoteType when possible. This makes reasoning
about where a specific load will complete easier.
3. Additional checks are made after a "WebContent" behavior is selected to
ensure that if an existing document in the same BCG is found, the load will
finish in the required content process. This should make dynamic checks such
as Android's logged-in site isolation easier to implement.
4. ProcessIsolation logging is split out from DocumentChannel so that it's
easier to log just the information related to process selection when
debugging.
5. Null result principal precursors are considered when performing process
selection.
Other uses of E10SUtils for process selection have not yet been migrated to the
new design as they have slightly different requirements. This will be done in
follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D120673
There are races which are more common after these patches where an implicit
about:blank load races with a speculative parent process load's process switch.
In this situation, bad behaviour can result as we process a navigation started
by a process which we process-switched away from. By tracking the explicit
ContentParent which is making the DocumentLoadListener request, we can catch
situations like this and avoid navigations being started from the wrong
processes.
Differential Revision: https://phabricator.services.mozilla.com/D120672
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
As it's usually not very useful. I don't know how easily we can add a
reliable test for this, let me know if you come up with an idea to do
that.
Differential Revision: https://phabricator.services.mozilla.com/D122222
This patch introduces a new type alias OkOrErr for Result<Ok, QMResult> and also converts some existing occurencies of Result<Ok, QMResult> to OkOrErr.
Differential Revision: https://phabricator.services.mozilla.com/D122206
On PowerVR devices we have seen reports of red lines and shapes
appearing randomly on the screen. What is happening is that clip masks
are being rendered in to the RGBA8 texture atlases that were the
previous pass' target, rather than the current R8 render target. Red
shapes therefore appear on top of the cached items in the RGBA texture
atlases, and parts of these subsequently get rendered to picture cache
tiles then the screen.
This appears to be due a bug with glInvalidateFramebuffer. We call
this function once we have finished using a render target for the
frame (ie we have rendered all items which need a clip mask). But
presumably, due to the asynchronicity of OpenGL, the draw calls to
render the clip masks to the render target are in fact still pending
at this point. Perhaps the driver incorrectly recycles the render
target's memory too early, and as a result the masks get written to
the wrong texture.
This patch therefore omits the calls to glInvalidateFramebuffer on
PowerVR devices. While this bug has been hard to reproduce reliably,
it appears to solve the issue.
Differential Revision: https://phabricator.services.mozilla.com/D122221
The SSE flags override must be sure to reset the SSE flags first, for
reasons already stated in the code. But if multiple flags are present
the semantics of the flag overrides is a little opaque. We clean this
up.
Cleanup turns out to be not straightforward due to an existing latent
bug: in the presence of parallel compiles and SSE flags overrides the
flag computations can become racy. We fix this here by forcing an
early computation of the flags and verifying that the flags are
computed before we spawn multiple threads.
There is a minor semantic change here in that the most restrictive
setting is now kept, while previously the last setting was kept, and
this was (given the structure of the calling code) always the least
restrictive setting. In practical terms this should not matter, and
if it does we can fix fallout later.
Differential Revision: https://phabricator.services.mozilla.com/D121953
The new tests in testing/xpcshell/example/ cover the following scenarios:
- Local AND remote xpcshell tests. In contrast, modifications to
selftest.py in bug 1635227 only covered runxpcshelltests.
- `prefs=` inheritance from ancestor manifests as implemented by
https://hg.mozilla.org/mozilla-central/rev/ac51a01611dc
- Per-file `prefs` setters (used in bug 1638099).
- Multiple prefs and comments per `prefs` line.
Differential Revision: https://phabricator.services.mozilla.com/D121632