This was not caught in tests because in a test both ProfD and ProfLD will map
to the same directory (e.g., on Windows they both map to
C:\Users\<username>\AppData\Local\Temp\<random>.mozrunner\).
Differential Revision: https://phabricator.services.mozilla.com/D140546
PathUtils::CreateUniquePath was doing main thread IO, so we're moving it to
IOUtils to use its event loop to do the IO.
Additionally, we're adding IOUtils::CreateUniqueDirectory which is the same as
::CreateUniqueFile, but for directories.
Differential Revision: https://phabricator.services.mozilla.com/D133841
PathUtils::CreateUniquePath was doing main thread IO, so we're moving it to
IOUtils to use its event loop to do the IO.
Additionally, we're adding IOUtils::CreateUniqueDirectory which is the same as
::CreateUniqueFile, but for directories.
Differential Revision: https://phabricator.services.mozilla.com/D133841
PathUtils::CreateUniquePath was doing main thread IO, so we're moving it to
IOUtils to use its event loop to do the IO.
Additionally, we're adding IOUtils::CreateUniqueDirectory which is the same as
::CreateUniqueFile, but for directories.
Differential Revision: https://phabricator.services.mozilla.com/D133841
- Updates Gecko's L10nRegistry class to use the new ResourceId type,
which can be either optional or required regarding a particular resource.
- Adds JS tests verifying the new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D133578
TabUnloader.jsm can directly call windowGlobal.hasActivePeerConnections(),
so windowContext.hasActivePeerConnections is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D132654
This patch makes sure the Tab Unloading feature does not unload tabs that have
active peer connections not to disrupt browsing experience based on WebRTC peer
connections.
To enable JS code to access the number of active peer connections, this patch
moves `nsPIDOMWindowInner::mTotalActivePeerConnections` to `WindowGlobalParent`.
Differential Revision: https://phabricator.services.mozilla.com/D128761
Previously, if you attempted to read a file greater than INT32_MAX in size, we
would either fail to read the file (on release) or crash (on debug). This is
due to the implementation of _PR_MD_READ accepting an int32_t of bytes to read
instead of a uint32_t, which nsFileStream::Read accepts and passes on.
Differential Revision: https://phabricator.services.mozilla.com/D131161
CLOSED TREE
Backed out changeset 55165cf4b7bb (bug 1736175)
Backed out changeset 492f5ca3b592 (bug 1723082)
Backed out changeset ce199e98a0c5 (bug 1741247)
Previously, if you attempted to read a file greater than INT32_MAX in size, we
would either fail to read the file (on release) or crash (on debug). This is
due to the implementation of _PR_MD_READ accepting an int32_t of bytes to read
instead of a uint32_t, which nsFileStream::Read accepts and passes on.
Differential Revision: https://phabricator.services.mozilla.com/D131161
This exposes synchronous file reading to workers. It's intended to be used
by profiler symbolication.
The API only supports reading into an existing Uint8Array. This avoids
creating garbage, and minimizes copies.
It also keeps the file open so that it doesn't need to be reopened for
each read.
The implementation uses nsFileStream.
I first tried an implementation which used mmap + memcpy rather than read,
but it didn't work for files larger than 2GiB due to limitations in NSPR's
mmap support, and the profiler needs to read >2GiB files.
Specifically, the profiler sometimes needs to read
/System/Library/dyld/dyld_shared_cache_arm64e , which is 2.2GiB big on
macOS 11.5.
Differential Revision: https://phabricator.services.mozilla.com/D124207
Chris Peterson
Barret Rennie
Nika Layzell
Csoregi Natalia
Cristian Tuns
Alexandre Lissy
Edgar Chen
criss
Butkovits Atila
Sandor Molnar
Erik Nordin
Toshihito Kikuchi
Richa Sharma
Alexandre Poirot
Florian Quèze
Norisz Fay
Alexandru Michis
Mathew Hodson
Randell Jesup
Markus Stange
Luca Greco