The property in question is the offset from the content process to the
chrome process, but it gets called various things for historical
reasons. Let's be consistent and just call it the chrome offset
everywhere.
Also, in some places this was needlessly getting turned into a
nsIntPoint via ToUnknownPoint(), only to be turned back into a
LayoutDeviceIntPoint at all the use sites. So this patch also updates
some function signatures to avoid the needless conversion.
No functional changes.
MozReview-Commit-ID: AuhEUfa64Uj
--HG--
extra : rebase_source : 20e1895fefd944f98307a8437f977252ee2c3185
Previously we used the MozPromise interface for calling an async-message over
IPC with a reply. Unfortunately, MozPromise processes the reply asynchronously,
potentially allowing other IPC messages to be processed before the `->Then`
callback is processed.
In the original CreateWindow patch I tried to work around this by setting the
target of the `->Then` callback to be StableStateEventTarget. This worked,
however as it isn't safe to run scripts etc. in the stable state, we instead
tried to exit the nested event loop immediately after the runnable ran, and then
performed processing of the reply.
Unfortunately, this bug exposed a problem with that design. If we have multiple
nested event loops then we cannot guarantee that we'll exit the nested event
loop immediately after recieving the `->Then` callback, which meant that we
could still process other IPC messages before we processed the CreateWindow
reply.
The fix to this was to add a new API to allow passing callbacks directly into
IPC send methods, ensure that those callbacks are called in IPC order, and
fully process the CreateWindow reply in the callback, rather than waiting for
the nested event loop to exit.
MozReview-Commit-ID: D6zaMJRxhXd
This patch moves handling of the "MOZ_DISABLE_CONTENT_SANDBOX" environment
variable into GetEffectiveContentSandboxLevel. It also introduces
IsContentSandboxEnabled and ports many users of GetEffectiveContentSandboxLevel
to use it.
MozReview-Commit-ID: 4CsOf89vlRB
--HG--
extra : rebase_source : b9130f522e860e6a582933799a9bac07b771139b
These were originally exposed directly as static methods on nsGlobalWindow, but
as they are clearly associated with either the inner or outer window, it makes
more sense for them to be called as such.
MozReview-Commit-ID: LFq8EfnhDlo
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
There's no good reason why these should't just be constants. The patch also
appends "MiB" to some of the C++ values to make their meaning clearer.
This patch fixes one outright bug, and one inconsistency.
The bug is due to a prefname mismatch:
- ContentPrefs.cpp and AvailableMemoryTracker.cpp use
"memory.low_virtual_mem_threshold_mb".
- all.js uses "memory.low_virtual_memory_threshold_mb".
Which means that "memory.low_virtual_memory_threshold_mb" showed up in
about:config, but if you changed it nothing would happen because the callback
listened for changes to to "memory.low_virtual_mem_threshold_mb"!
Now for the inconsistency. The above means we actually use a value of 256 for
the virtual memory threshold, even though all.js says 128. But we *do* use a
value of 128 for the commit space threshold, because that's what all.js says
and that prefname is used correctly everywhere. The patch changes the commit
space threshold to 256 for consistency with the virtual memory threshold.
What a mess!
--HG--
extra : rebase_source : d3842c732efa9ab0e90eeb6a4f341aeb289589ed
This was originally added for b2g, where the pref had a different value.
Bug 1398033 enabled it everywhere.
--HG--
extra : rebase_source : c8bb03190cd00d25e6c2ec62a99ed8e911e08197
There are up to two compositor threads spawned - one in the GPU process
and one in the UI/chrome process. If the GPU process is used, then
failing to start the UI compositor thread is not fatal -- unless the GPU
process crashes too much and we fallback to the UI/chrome process. If
the GPU process compositor thread failed to start, then the GPU process
will crash and either restart, or fallback to the UI/chrome process
thread. If both fail, then Firefox crashes as expected.
Before we would not setup a content process properly unless the
UI compositor thread was active, even when using the GPU process. Now we
do, which allows the browser to be fully functional. Additionally when
shutting down, we ignore the lack of a compositor thread to permit a
graceful shutdown. In a future patch we will ideally we would not spawn
the compositor thread in a process until we actually need it, and
release assert on its failing to start.
Don't retrieve parent display by DetectDisplay().
Utilize MOZ_GDK_DISPLAY when available, when it's missing query DISPLAY env variable for X11 only builds and standard gtk_init() for Wayland enabled builds.
MozReview-Commit-ID: 9yebsISeNjc
--HG--
extra : rebase_source : b6841727b3b6859ac51f7c5abf2d717116d3dc4d
And remove unreachable code after MOZ_CRASH().
MozReview-Commit-ID: 6ShBtPRKYlF
--HG--
extra : rebase_source : 0fe45a59411bda663828336e2686707b550144ae
extra : source : 8473fd7333d2abe1ea1cc176510c292a5b34df45
Minor note:
reftests should've turned off uploadEnabled in the first place.
reftests should have unified telemetry on. It's the future.
MozReview-Commit-ID: 9spzuUAXwwP
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive. This patch splits that macro into three new ones that are harder to
mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 3e2bbec4737b696e1c86579ae54be4cb3186c100
The two happening at the same time can lead to the APZ autoscroll being
cancelled due to APZ receiving a main-thread scroll offset update.
To achieve this:
- The content process assumes APZ is handling the autoscroll until
told otherwise.
- If the parent process knows APZ won't handle an autoscroll, it
tells the content process via its response to the Autoscroll:Start
message. This covers all cases where APZ doesn't handle the
autoscroll, except the case where APZCTreeManager itself rejects
the autoscroll and it lives in the compositor process rather than
the parent process.
- If APZCTreeManager rejects an autoscroll and it lives in the
compositor process, it sends an 'autoscroll-rejected-by-apz' message
to the content process.
MozReview-Commit-ID: L62v4COai6W
--HG--
extra : rebase_source : bc4c6417e77461634263defb88e67ed5036c454e
This is needed since the pref will be sent with the first IPC message as soon
as the content process starts. Without this, it crashes on debug builds.
MozReview-Commit-ID: 3mGwEkaJF7n
--HG--
extra : rebase_source : 42f8d29bf9b74a42b08156ad07f262323b42c72b
This patch includes a bunch of somewhat related fixes, these are:
- Ensuring that when a mochitest calls SimpleTest.expectChildProcessCrash()
the harness will wait for the crashes to be recorded before deleting the
dump files. This involves a message round-trip between the content and
parent process so to minimize its performance impact on all the non-crashing
tests it is done only when required.
- As an additional optimization, the SimpleTest harness will not send a
message to the content process anymore whenever it receives an
ipc:content-shutdown event, instead it does it only for abnormal shutdowns.
- Manually fixing remaining mochitests causing crashes to wait for crashes to
be recorded before finishing and deleting the dump files.
- Modifying BrowserTestUtils.crashBrowser() so that it optionally does not
delete the dump files, this is useful for tests that submit their dumps and
thus delete them on their own.
MozReview-Commit-ID: 4SLJ8BjJ18n
--HG--
extra : source : b5452a41bb962c6929292c5c538e19ac28d84fe7
In come cases, we can fail the IPC message, but in one we can't really do anything.
MozReview-Commit-ID: 4vdKIRUOJNN
--HG--
extra : rebase_source : b32559b4d88017612c35346f83cb11cb5b522252