Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
Most of them just want GetRootFrame(), and there's no need to explicitly go
through the frame manager for that, we have a handy alias in the shell.
MozReview-Commit-ID: GriEqkasidY
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : 40b29d34e5cc99f9b8e6d5e711a03b9fe9bfa595
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : e455f934e6e6d65d54c122a6cec9f6cabbd5ac78
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : d7c026d8a77634ef2566feba78168beb8a66a552
The canvas prompt is extremely annoying. It happens everyone, automatically. And in
99.9% (not scientific) of cases it is not triggered by user input, but my automatic
tracking scripts.
This commit will automatically decline the canvas read if it was not triggered by
user input.
Just in case this breaks something irrepairably, we have a cutoff pref.
We don't intend to keep this pref forever, and have asked anyone who sets it to
tell us why.
MozReview-Commit-ID: CxNkuraRWpV
--HG--
extra : rebase_source : 12cfc94cecbd378c0859ae50066c6338bcaa6692
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
"consoleservice.logcat" can apparently be accessed early enough in the
content process. This is only a problem when running GeckoView under
e10s.
MozReview-Commit-ID: DvOJphIZrXz
--HG--
extra : rebase_source : 04628d12df49646ade2711063fa548f5cd7c7c7b
The meaning of "possibly-changed" is provided by the big comment above
MustSendToContentProcesses.
On a new profile this reduces the number of prefs sent like so:
- Command-line: 222 --> 3
- IPC: 3129 --> 130
On an older profile:
- Command-line: 222 --> 3
- IPC: 3165 --> 180
MozReview-Commit-ID: DcgedhXhZd8
--HG--
extra : rebase_source : acef424fab5031347cbcbd5c3e6a24ee66895ef9
When ContentChild::RecvInitRendering is received, it tries to setup the
IPDL actors related to rendering. If the GPU process crashes before or
during this process, it will fail, and cause the content process to
crash as well. This is unnecessary because the UI process will either
restart the GPU process, or subsume its job into itself, and trigger
ContentChild::RecvReinitRendering. It is a similar case for failures in
ContentChild::RecvReinitRendering.
Since the GPU process crashing should be a recoverable scenario, we now
check if the remote IPDL actor is in the UI or the GPU process. If it is
in the UI process, it will fail/crash as it does today. If it is in the
GPU process, it will wait for the next
ContentChild::RecvReinitRendering.
For failures that are not IPDL related (e.g. failed to get some resource
like spawning a thread), we release assert specifically for those
failures. They are not recoverable.
With this change, the macOS content sandbox has no ability to create files
anywhere on disk (in release builds). If the content process needs a file to
write to, it needs to obtain a file descriptor from the parent process.
MozReview-Commit-ID: 7LoG1PW0UDR
--HG--
extra : rebase_source : 4ac0a7f187d45c9b6c0f8a658edfdae0509054ac
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
--HG--
extra : rebase_source : a81263a0ef97a8ed87129d15ef30ded3005e740c
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
--HG--
extra : rebase_source : a81263a0ef97a8ed87129d15ef30ded3005e740c
nsIDOMWindowUtils::sendKeyEvent() is already replaced with nsITextInputProcessor
for making callers set any attributes of KeyboardEvent and guaranteeing
consistency behavior with keyboard events caused by native key events. E.g.,
whether keypress event should be dispatched or not is automatically decided.
nsIFrameLoader::sendCrossProcessKeyEvent() is similart to
nsIDOMWindowUtils::sendKeyEvent() but it dispatches keyboard events in
child process directly. Currently, nsITextInputProcessor doesn't have this
feature but nobody wants/uses this feature. So, for removing actual
implementation of nsIDOMWindowUtils::sendKeyEvent(), i.e.,
nsContentUtils::SendKeyEvent(), which is shared by both
nsDOMWindowUtils::SendKeyEvent() and nsFrameLoader::SendCrossProcessKeyEvent(),
we should remove this unused API too. (FYI: it's implemented for old Fennec,
by bug 553149.)
MozReview-Commit-ID: 9n0UVo8Me8k
--HG--
extra : rebase_source : e9b117f5b9afec76e63d57ab8cd86dafb5873789
