Convert all other imports of `pytoml` within mozilla-central to imports
of `toml`.
As both libraries patterned their API on that of the Python standard-
library module `json`, this is mostly a straight replace, with two
caveats:
* pytoml's exception messages when loading a file provide the file
name; toml's do not. Some additional machinery has been added or
repurposed in a few places to ensure that the relevant filename is
printed.
* In `python_lockfile.py`, the order of arguments to `dump` needed to
be reversed. (`toml` follows `json` in this; `pytoml` differs.)
This patchset does not remove pytoml from `requirements.in`, as `pytoml`
is still used by `compare-locales`.
Differential Revision: https://phabricator.services.mozilla.com/D164155
`pytoml` could not handle single-quoted keys in table names, as these
were added in TOML v0.5.0; but `toml` has no problem with them.
Remove regex-based scraping of Cargo.toml files to find a crate's
associated license, replacing it with `toml.load`.
(This has been manually tested to ensure that dependencies with
noncompliant licenses or unrecognized license files continue to be
rejected.)
Differential Revision: https://phabricator.services.mozilla.com/D164154
The postprocessing phase that cleaned up `pytoml`'s output has little
effect on `toml`'s output, which is already largely clean. Remove the
additional code.
Differential Revision: https://phabricator.services.mozilla.com/D164153
Remove explicit sorting, as this is no longer needed to guarantee
determinism as of Python 3.6 (our minimum-supported version).
(This is a separate commit solely to make it clear that the reordering
of `.cargo/config.in` is indeed merely a reordering and contains no
hidden functional changes.)
Differential Revision: https://phabricator.services.mozilla.com/D164152
Replace `pytoml` with `toml` in `vendor_rust.py`.
This is a minimal substitution that preserves existing behavior (along
with a flake8 lint pass). Further simplification will follow in upcoming
commits.
In particular, we temporarily alter `recursive_sort` to ensure that the
output of `pytoml` and `toml` are identical, rather than merely
equivalent. (`pytoml` would reverse the ordering of keys in some
contexts.)
Differential Revision: https://phabricator.services.mozilla.com/D164151
The `pytoml` library is abandoned, and does not support TOML v0.5.0,
which Cargo uses. This prevents mach from properly parsing many
Cargo.toml files.
Include the `toml` library as a slightly more modern and currently-
maintained alternative for use in mach.
Supply-chain notes:
- toml v0.10.2 is MIT-licensed, which is an approved MPL-compatible
license.
- I have personally audited this version of `toml` and consider it
"safe-to-run", as much as any Python code can be: other than opening
and reading/writing a file when specifically requested via `load`/
`dump` respectively, it performs only string manipulation and
ordinary object creation.
Differential Revision: https://phabricator.services.mozilla.com/D164150
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
Ensures that:
1) We never have stats report in a still-registered PC _and_ the stats for
closed PCs.
2) We never have a stats report disappear between when a PC is closed, and when
it deregisters.
3) If a stats report appears in WebrtcGlobalInformation as closed, a call to
ClearAllStats will ensure that this stats report does not reappear later
when the PC dereigsters.
Also simplifies things a bit.
Differential Revision: https://phabricator.services.mozilla.com/D162652
Also fix bugs where we would get duplicate ICE stats. This mostly mattered to
WebrtcGlobalInformation since RTCStatsReportInternal does not automatically
remove duplicate ids like RTCStatsReport (RTCStatsReport is maplike).
Differential Revision: https://phabricator.services.mozilla.com/D162322
If we decide to cancel an request, fetch request needs it to be done before
FetchDriver::OnStartRequest is called, otherwise it'll resolve the
promise and we want it to throw for ORB.
Depends on D163283
Differential Revision: https://phabricator.services.mozilla.com/D165032
For things that can be parsed as Javascript, we need to figure out
if they are JSON, and we want to block opaque JSON resources for ORB.
This initial version just checks the first byte of the response, and
blocks it if it's a curly bracket.
Differential Revision: https://phabricator.services.mozilla.com/D163283
This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish _after_ the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.
Depends on D155690
Differential Revision: https://phabricator.services.mozilla.com/D155568
In our implementation, we do not have "client" as a referrer, so we resolve the URI directly as part
of ScriptLoadRequest creation.
Depends on D147327
Differential Revision: https://phabricator.services.mozilla.com/D155567
ImportScripts should be disallowed for module works, which are initialized in the following way:
`new Worker("url", { module:true})`. We set the WorkerType for workers accordingly, and can use that
to detect if import scripts are being incorrectly used.
Depends on D147326
Differential Revision: https://phabricator.services.mozilla.com/D147329
This implements a method to initialize the moduleLoader for workers. This will initialize only once, for all worker types (module and classic).
Depends on D147324
Differential Revision: https://phabricator.services.mozilla.com/D147326
See part 1 for an explanation of the attribute. To my approximation,
these messages appear to be ones which should be OK to delay sending
until another message is sent, or an idle runnable is fired, as they
largely set up state in the receiving process for future messages.
I tried not to be too aggressive at least at first, and this attribute
is fairly safe, so it is possible that we could get some benefits from
many more messages being annotated with it in the future.
Differential Revision: https://phabricator.services.mozilla.com/D164276
This is intended to be used to mark messages which do nothing on the
receiving side other than setting up state for future IPC messages,
meaning that the send can be delayed until other more important work is
complete, or until a non-LazySend IPC message is sent.
This does not break any message ordering guarantees, as the lazy
messages will be sent in order before any non-lazy messages are sent.
Differential Revision: https://phabricator.services.mozilla.com/D164274
The only consumer of this feature has been removed, so we don't need it
anymore. It acts very differently than other runnables run on the main thread,
so removing it will simplify things.
Differential Revision: https://phabricator.services.mozilla.com/D164841
The reason this was originally added was for bug 1516277 in order to allow a
synchronous dispatch to a background thread to create a new PBackground
instance without deadlocking. The dispatch didn't want to support running other
main thread runnables, but needed to support sending the runnable to create a
new PBackground instance on the main thread.
This is no longer an issue since bug 1737828, where we changed PBackground
startup to no longer require the main thread, so we can remove the complexity
and instead use a monitor to handle changes. This also allows removing the
timer, as the monitor's timeout can be used instead.
I also changed the logic slightly to make it more likely to catch an expecting
shutdown by waiting on the monitor with a timeout, as previously the main
thread would not be being woken up and checking the condition very often, due
to it not having any runnables to execute.
Differential Revision: https://phabricator.services.mozilla.com/D164840
This should avoid the crash caused by the CacheOutputCloseListener being
fired on the main thread too late during shutdown by keeping the
previous behaviour when on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D165062
Tom Schuster
Marian-Vasile Laza
Randell Jesup
Otto Länd
Ray Kraesig
Kelsey Gilbert
Byron Campen [:bwc]
Sean Feng
James Teow
owlishDeveloper
Ryan VanderMeulen
alwu
Tom Ritter
Julian Descottes
Yulia Startsev
Nika Layzell
Edgar Chen
Michael Froman