Fix for the following scenario:
- "Don't keep activities" checked
- Change system language
Upon detecting a locale change in BrowserApp's onCreate() we would call
finish() and then return before calling super.onCreate().
This patch introdues the call to super.onCreate() before returning and ensures
that the app will die cleanly so that upon restarting Gecko can reinit add-ons
that touch the UI.
Differential Revision: https://phabricator.services.mozilla.com/D35402
--HG--
extra : moz-landing-system : lando
This adds an API for fetching security info per frame, no matter if we have
a certificate error or a valid certificate.
I tried to make this work in a Fission-compatible way, let me know if this
is the right approach.
Differential Revision: https://phabricator.services.mozilla.com/D34354
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Bug 1284835 removed the hard-coded learn more link on cert and net error pages, which worked
for cert error pages because they explicitly set their own learn more links, but net error
pages were relying on the default href to be set. This wasn't revealed until bug 1530348
made about:neterror part of the new error pages.
The solution is simply to explicitly set the correct learn more link to net error pages.
Note that in the case of PR_END_OF_FILE errors, we were not previously showing a "learn more"
link. That was not intentional, as far as I can tell, but was caused by the bug fixed in bug 1477875.
Differential Revision: https://phabricator.services.mozilla.com/D35163
--HG--
extra : moz-landing-system : lando
Removed helperthread_ and its associated functions since they are no longer used & cleaned up a few missed checks that used it. Changed helperThread()->parseTask() checks to look for cx->parseTask() instead.
Differential Revision: https://phabricator.services.mozilla.com/D35491
--HG--
extra : moz-landing-system : lando
Added a ParseTask pointer to JSContext, set/removed during ParseTask::runTask
Differential Revision: https://phabricator.services.mozilla.com/D35365
--HG--
extra : moz-landing-system : lando
Also refactor SharedMemoryBasic::SystemProtect to allow testing cases
that are expected to fail.
Depends on D26748
Differential Revision: https://phabricator.services.mozilla.com/D26749
--HG--
rename : ipc/moz.build => ipc/gtest/moz.build
extra : moz-landing-system : lando
If mmap failed, we'd leave the memory_ member variable set to MAP_FAILED,
but everything else in this file checks for nullptr (and only nullptr) to
test if the pointer is valid.
Also, this removes the debug assertion that the mmap succeeded, to allow
writing unit tests where we expect it to fail (e.g., for insufficient
permissions).
Depends on D26747
Differential Revision: https://phabricator.services.mozilla.com/D26748
--HG--
extra : moz-landing-system : lando
With the removal of the old Chromium file_util code, we should no longer
be using temporary files with names starting with "org.chromium.", so the
crash reporter and main thread I/O test no longer need to recognize that
prefix.
Differential Revision: https://phabricator.services.mozilla.com/D34629
--HG--
extra : moz-landing-system : lando
There was a strange bug when converting SharedStringMap to use shared
memory: on Android, some tests would fail because a pref wasn't set or
there was something wrong with an expected error message. The root
cause was that mapping ashmem with MAP_PRIVATE results in all zeroes
(see bug 1525803), but that was read as a valid SharedStringMap with
length 0.
To prevent any possible future issues like that, this patch adds a
nonzero magic number to the header. It fits into padding on 64-bit and
the cost of setting and checking it should be essentially free.
Depends on D26744
Differential Revision: https://phabricator.services.mozilla.com/D26745
--HG--
extra : moz-landing-system : lando
One problem with using shared memory instead of files for MemMapSnapshot
is that AutoMemMap was trying to use fstat() to obtain the object size;
that doesn't work with ashmem on Android and was causing problems with
the Mac sandbox, but it's not necessary, because we already know the
size. This patch changes it to not do that.
Depends on D26743
Differential Revision: https://phabricator.services.mozilla.com/D26744
--HG--
extra : moz-landing-system : lando
This allows writing to shared memory and then making it read-only before
sharing it to other processes, such that a malicious sandboxed process
cannot regain write access. This is currently available only in the
low-level base::SharedMemory interface.
The freeze operation exposes the common subset of read-only shared
memory that we can implement on all supported OSes: with some APIs
(POSIX shm_open) we can't revoke writeability from existing capabilies,
while for others (Android ashmem) we *must* revoke it. Thus, we require
that the writeable capability not have been duplicated or shared to
another process, and consume it as part of freezing. Also, because in
some backends need special handling at creation time, freezeability must
be explicitly requested.
In particular, this doesn't allow giving an untrusted process read-only
access to memory that the original process can write.
Note that on MacOS before 10.12 this will use temporary files in order to
avoid an OS security bug that allows regaining write access; those OS
versions are no longer supported by Apple (but are supported by Firefox).
Depends on D26742
Differential Revision: https://phabricator.services.mozilla.com/D26743
--HG--
extra : moz-landing-system : lando
The tests for unexpected main thread I/O had exemptions for the specific
paths that were being used for shared memory, which would cause it to
fail with the changes in this bug. This patch does two things:
1. On Linux, /dev/shm is always tmpfs (a memory filesystem), so it's not
going to cause disk I/O, and it's used by glibc to implement the POSIX
standard shm_open API. This allows all /dev/shm paths instead of
limiting it to a hard-coded prefix.
2. On MacOS, with the patches in this bug, we'll no longer use temporary
files for shared memory on current OS versions, but we still need them on
older versions to avoid an OS bug (https://crbug.com/project-zero/1671),
and they are backed by disk in this case, so we want to allow only the
IPC files. However, the path prefix has changed.
Differential Revision: https://phabricator.services.mozilla.com/D34628
--HG--
extra : moz-landing-system : lando
This uses RAII to handle error-case cleanup in the POSIX backend for
SharedMemory::Create, to simplify the complexity that will be added to
support freezing.
Depends on D26741
Differential Revision: https://phabricator.services.mozilla.com/D26742
--HG--
extra : moz-landing-system : lando
The Unix backend for shared memory needs to keep the mapped size to pass
to munmap, while the Windows backend doesn't. Currently it's reusing the
max_size field, and then zeroing it when it's unmapped, which breaks the
freezing use case. This patch uses a dedicated field for that.
Depends on D26740
Differential Revision: https://phabricator.services.mozilla.com/D26741
--HG--
extra : moz-landing-system : lando
Despite the comment saying not to use the "handle" except as an opaque
identifier, it is being used to pass the handle to other OS APIs. Direct
access to the handle needs to be controlled to make sure freezing is
safe, so this patch replaces that with interfaces that are more explicit
about ownership and lifetime.
Depends on D26739
Differential Revision: https://phabricator.services.mozilla.com/D26740
--HG--
extra : moz-landing-system : lando
FreeBSD's SHM_ANON is useful for the usual case of shared memory, but it
doesn't support freezing. It could be re-added later, but for now it's
simplest to remove it (and use named shm instead) while refactoring.
Depends on D26738
Differential Revision: https://phabricator.services.mozilla.com/D26739
--HG--
extra : moz-landing-system : lando
Now that UniqueFileHandle can be used more widely, and with
ipc::FileDescriptor being essentially a copyable UniqueFileHandle, it
makes sense to add a move constructor and a "forget"-like method to
convert between them when needed.
Depends on D26737
Differential Revision: https://phabricator.services.mozilla.com/D26738
--HG--
extra : moz-landing-system : lando
Various callers either already call it or should but are forgetting to. The exception is WorkerDebuggerGlobalScope_Binding::Wrap, but it should be OK to set up the profiling functions there too.
Differential Revision: https://phabricator.services.mozilla.com/D35458
--HG--
extra : moz-landing-system : lando
