This change comes in two parts. First, the code in WindowGlobalChild was changed
to detect the in-process case, and instruct the nsFrameLoader to become a
non-remote nsFrameLoader, and second the logic in WindowGlobalParent was updated
to ensure that the OwnerProcessID is updated after the change.
Differential Revision: https://phabricator.services.mozilla.com/D35060
--HG--
extra : moz-landing-system : lando
Because the return address cannot be used to uniquely identify script/pc, this
is unfortunately quite different from what we do for Baseline/Ion code.
The strategy is as follows:
* When the profiler is enabled, ensure each JitScript has a pointer to the
profile string (released when the script is finalized).
* The BaselineInterpreter code is registered with the JitcodeMap.
* The profiler code treats interpreter frames like C++ Interpreter frames,
instead of doing the return address based mapping.
Differential Revision: https://phabricator.services.mozilla.com/D31052
--HG--
extra : moz-landing-system : lando
This makes running without mach more consistent. e.g. running
`make -C $objdir/toolkit/library/rust target` makes the cargo log
verbose, and adding `-s` makes it less verbose.
Differential Revision: https://phabricator.services.mozilla.com/D35521
--HG--
extra : moz-landing-system : lando
When the `MOZ_RUST_TIER` environment variable is set, we enable a separate
tier that builds rust code only. This is useful to measure build times for
rust code separately from other compilations.
Differential Revision: https://phabricator.services.mozilla.com/D35501
--HG--
extra : moz-landing-system : lando
Fixed an issue where we were trying to set some attributes on a null object due to the fact that
the view had not finished rendering.
Differential Revision: https://phabricator.services.mozilla.com/D35515
--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
This changes CreateClippedDrawTarget so that instead of taking
a max size and a transform it just takes a user space rect of
the desired bounds.
This change allows the caller to not worry about the computing
a max size based on the current clip. Instead this responsibility
is lowered into the specific backends.
The main motivation for this work is to allow blob recoordination
to create recordings that don't depend on the current clip.
Some additional benefits are that the API is easier to use and
as can be seen simplifies the SVG masking code because it doesn't
need to track surface offsets manually.
It's also an important step towards removing all the uses of
gfxContext::GetClipExtents which will let us get rid of the separate
clipping stack in gfxContext and help us move off of gfxContext
completely.
Most backend implementations of CreateClippedDrawTarget are relatively
simple. DrawTargetCapture is modified to track the current clip rect
so that it can create a new DrawTargetCapture of the appropriate size
without needing to worry about lazy resolution.
Differential Revision: https://phabricator.services.mozilla.com/D33363
--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
