We want to avoid to have several cached content processes, one for each
preloaded browser (one per window) and one for the preallocated process.
For that we force the preloaded browser to choose an existing process and
during the first navigation in that tab, that leaves about:newtab, we re-run
the process selecting algorithm
This gives JS callers access to the remote type of remote message managers.
There's currently no way for extensions to access this unless they have a
<browser> element to check the remoteType attribute of.
MozReview-Commit-ID: A8Y3ZSG3rt8
--HG--
extra : rebase_source : e024922522da9a30265f05e9a8dbf7529dfe1d81
JS code is notified when a new ContentParent is created via normal
"ipc:content-created" notifications, but can't do anything with it, since
nsIContentParent is not scriptable. This allows JS callers to retrieve the
parent process message manager, which is the normal way they interact with
content children.
MozReview-Commit-ID: 7lcZ4XkJ6uR
--HG--
extra : rebase_source : f891c0e29863fc42fc2351a791ca3f1f7e2824b9
We want to avoid to have several cached content processes, one for each
preloaded browser (one per window) and one for the preallocated process.
For that we force the preloaded browser to choose an existing process and
during the first navigation in that tab, that leaves about:newtab, we re-run
the process selecting algorithm
I don't bother to label the runnables in the parent process being fired by
VisitedQuery, as we are not planning to perform scheduling in the parent process
if I remember correctly. It would be possible to label those runnables as well.
MozReview-Commit-ID: EosNOu62fEV
Telemetry has indicated that preference update messages are one of the
most common unlabeled runnables. Starting the browser on a clean
profile and letting it just sit for a few minutes shows many prefs being
broadcast to all content processes that won't really have any effect on
said content processes--preference changes having to do when services
were last checked for updates and things like that. To cut down on
preference update traffic, this patch introduces a simple blacklist
against which all preference updates are compared. This should cut down
on preference update traffic and reduce the number of unlabeled
runnables to worry about.
We want to avoid to have several cached content processes, one for each
preloaded browser (one per window) and one for the preallocated process.
For that we force the preloaded browser to choose an existing process and
during the first navigation in that tab, that leaves about:newtab, we re-run
the process selecting algorithm
BHRTelemetryService only runs in the parent process (and we can only submit
pings from there), so we need to send the data which we collect in the GPU and
Content processes over IPC to the parent process.
MozReview-Commit-ID: 8B5uZKbjNbU
We want to avoid to have several cached content processes, one for each
preloaded browser (one per window) and one for the preallocated process.
For that we force the preloaded browser to choose an existing process and
during the first navigation in that tab, that leaves about:newtab, we re-run
the process selecting algorithm
Moves IsDevelopmentBuild(), GetRepoDir(), and GetObjectDir() out of
SandboxSettings because they also need to be used by ExtensionProtocolHandler
to do security checks on developer builds as a result of how developer builds
rely on symlinks to the repo dir from system extension directories.
Remove the Linux-implementation of GetRepoDir() and GetObjectDir()
because the Linux content sandbox implementation and the
ExtensionProtocolHandler checks don't need them.
MozReview-Commit-ID: KwBFUnh6Cml
--HG--
extra : rebase_source : 3529a18ea802699ff968b798a7c560613469809b
In all of these cases the fixed buffer has the same lifetime as the string
object, so we can use nsAuto[C]String for simplicity.
For the 128-length ones in dom/xul/ I just switched to the default of 64 for
simplicity, because the choice of 128 didn't seem that important. (These code
paths weren't hit when I started the browser and opened a few sites.)
Finally, the patch also changes LoggingIdString to use
nsAutoCStringN<NSID_LENGTH>, similar to NullPrincipalURI.
Without this patch, all remote process types share a process name of
"Web Content". With this patch, specific names are added for "file",
"extension", and "webLargeAllocationTypes", with the default of "web"
left as the default "Web Content".
This patch also eliminates undocumented b2g-era legacy logic that had a
notion of whether it's acceptable to override the process name. In the
b2g era, I believe processes were named based on the "app" that was
running. It would have made sense to have the process initially named
the preallocated process, then to change the process to its app name
when specialized, trying to make it hard/impossible for the process to
rename itself so it couldn't masquerade as another app if it became
compromised.
--HG--
extra : source : c76be2df2c2855ddf2fafc323ddb2898dd65eba4
nsXPIDLStrings are marked as VOIDED upon initialization. Most of these local
nsXPIDLString variables are immediately set via getter_Copies(), which will
either assign a string value (using Adopt()) or do SetIsVoid(). These can be
trivially converted to nsString, which will get the same treatment.
The patch suitably converts the remaining nsXPIDLString local variable as well.
--HG--
extra : rebase_source : 5fff9f2c6844559198f601853f8db08564add7d5
Android now supports telling an IME that it shouldn't store user-entered content into it's dictionary/language model/etc. and we want to automatically enable this in private browsing.
As the code that handles input on Android doesn't have any notion of tabs (and therefore of the difference between normal and private tabs), the best way to get that info across is to retrieve it directly within the IMEStateManager from the corresponding document and store it in the inputContext, which is then passed to Java for Fennec to handle.
Implementing this within Gecko also has the benefit that this part of the code can be used by other platforms as well should they want to support similar features in the future.
MozReview-Commit-ID: DsxjC4Ma7DR
--HG--
extra : rebase_source : f0940cb40170ab32cf5a172d07a61d083427be8a
The messages are routed through nsITabParent, nsIWidget, and IAPZCTreeManager
(the latter possibly remoted via PAPZCTreeManager if out-of-process compositing
is used).
MozReview-Commit-ID: 1zXzLa1fqpG
--HG--
extra : rebase_source : c482816ecbaec0a889d817851ee15be186b2a49c
This is similar like the previous patch, but for the 8-bit string variants.
Also, it changes assignment to Adopt() in GetCString() and GetDefaultCString()
to avoid an extra copy.
--HG--
extra : rebase_source : eba805c3a7b809d5ccd6e853b1c9010db9477667
Some tests were using "secret" APIs to get at telemetry knowledge from various
processes in various ways. Adjust them so that they work with the new ways of
doing things.
MozReview-Commit-ID: 2iBL00HVGyg
Some tests were using "secret" APIs to get at telemetry knowledge from various
processes in various ways. Adjust them so that they work with the new ways of
doing things.
MozReview-Commit-ID: 2iBL00HVGyg
On Mac developer builds, read the repo path and object dir path from the
Info.plist files in the application bundle instead of the
MOZ_DEVELOPER_REPO_DIR and MOZ_DEVELOPER_OBJ_DIR environment variables.
MozReview-Commit-ID: 8UtjkNPGUM1
--HG--
extra : rebase_source : 3e4ce32f2e2c40f8d899bc9190e48298081458d9
We removed all uses of GetBlocklistState in bug 1350640. This patch
removes the message and supporting functions from the PContent IPDL.
MozReview-Commit-ID: 4JtGAWZ0nPu
--HG--
extra : rebase_source : 4eb3c21e3768e9d8284d4eec129e099be5ef17d0
Instead of synchronously checking the blocklist, package each plugin's
blocklist state with it when sending the information to the content
process. Whenever the blocklist is changed, just resend the whole
plugin list.
MozReview-Commit-ID: 1AX1EDdTRqb
--HG--
extra : rebase_source : 95d30f23eaede357bfb03757a7d9a6cc62e2adf9
The current code is wrong in several ways when transforms are applied, but
even if it were correct, it would give the wrong behavior. See comment in
patch for more details.
MozReview-Commit-ID: 3RaPuvENnWa
--HG--
extra : rebase_source : 25aab67e56f157bdfa500aa7cf029c6ebe90e12a
extra : absorb_source : 4da2fd9f11e008b7b70b86b184ade673a68e6978
On-screen coordinates for points in remote frameloads are calculated relative
to the screen origin of the top-level window, while event coordinates are
calculated relative to the nearest widget. Since popups have their own widgets
separate from the top-level window, their native client offsets have no
particular relation to the origin of the top-level window, and we need to
manually calculate them relative to the origin of the top-level widget
instead.
MozReview-Commit-ID: EDyEyu37XuY
--HG--
extra : rebase_source : 5d3f7a3fb9518d7a0cf149b8c2f579805d75eb3b
extra : absorb_source : f48ee4b131ff67ae686d12f81ed2ad19b934e81e
On developer builds, use $MOZ_DEVELOPER_OBJ_DIR to whitelist the object dir in the content sandbox so that symlinks to the object dir from .app/ files can be loaded.
MozReview-Commit-ID: J4YdpxgbD8i
--HG--
extra : rebase_source : 19e369fe9ae29418d9d79e1fb83246474d858f34
Currently, access key is handled in EventStateManager::PreHandleEvent() with eKeyPress event, i.e., before dispatching it into the DOM tree, if the access key is registered in EventStateManager. So, the main process does not check if the preceding eKeyDown event is consumed in focused remote process.
When preceding eKeyDown event is consumed in the main process, eKeyPress event won't be dispatched by widget. However, if remote process has focus, it's impossible widget to stop dispatching eKeyPress event because preceding eKeyDown event hasn't been handled in the focused remote process yet. Therefore, main process needs to post eKeyPress event to check if preceding eKeyDown event was consumed. When eKeyPress event is marked as "waiting reply from remote process", TabChild sends it back to the main process only when preceding eKeyDown event wasn't consumed. So, only when eKeyPress event is back to the main process, main process should handle accesskey with it.
This patch makes EventStateManager::PreHandleEvent() check if a remote target has focus before handling accesskey. If a remote process has accesskey and there is an accesskey matching with eKeyPress event, it marks the event as "waiting reply from remote content" and stop propagation in the process.
Finally, when eKeyPress event is sent back to TabParent, TabParent::RecvReplyKeyEvent() calls EventStateManager::HandleAccessKey() before dispatching the reply event into the DOM tree.
MozReview-Commit-ID: KsOkakaIVzb
--HG--
extra : rebase_source : 7e0c6966a1bde085e34d45bca4b0166b9fc2f3f1
EventStateManager checks if every keypress event's modifiers match with access key modifiers which are in prefs. Moving related methods of this to WidgetKeyboardEvent makes EventStateManager simpler and we can hide the NS_MODIFIER_* constants (they may make developers confused between Modifiers of WidgetInputEvent) into WidgetEventImpl.cpp.
MozReview-Commit-ID: 23NUQ51lJ1M
--HG--
extra : rebase_source : 341f3764ef62575577572d8b349159e2d5512b26
We should not let the ppm to do work before the first paint in a new cp. This patch
makes sure that we only let the ppm spawn a new process after the last process reached
an idle state AND the main process becomes idle too.
IME should receive notifications and requests only from proper process. E.g., IME shouldn't commit composition by a request which came from previous focused process.
This patch makes that IMEStateManager::NotifyIME() takes pointer to TabParent optionally. If the request or notification came from remote process, it should be non-nullptr. Then, this makes it ignore notifications and requests from unexpected process.
Note that this patch also touches some gfx headers because they use |ipc::| but compiler is confused at the ambiguousness between |mozilla::ipc::| and |mozilla::dom::ipc::|.
Finally, this patch changes the NS_ASSERTION in IMEHandler::OnDestroyWindow() to MOZ_ASSERT because the orange caused by the NS_ASSERTION was not realized since there was already an intermittent orange bug caused by different NS_ASSERTION.
MozReview-Commit-ID: 9CgKXQRJWmN
--HG--
extra : source : f3b5711908870c5e0e852a399a07e0ae721a12f1
This extracts a BaseMatrix template of which Matrix is now a particular
specialization. The BaseMatrix allows us to reuse the same code for
floats and doubles, much like the other "base" classes (BasePoint,
BaseRect, etc.).
MozReview-Commit-ID: HO7bA83S9E0
--HG--
extra : rebase_source : dcd84d9a978cdea00bb54eb11eefcca9c6635901
Currently, it's not been managed yet that whether an event is posted to at least one remote process. So, for managing the state, BaseEventFlags should have a new bool flag and WidgetEvent and BaseEventFlags should have helper methods for it.
Additionally, this fixes a bug of nsGUIEventIPC.h. In a lot of ParamTraits, static_cast<Foo> is used for using base class's ParamTraits. However, it causes creating temporary instance with copy constructor. Therefore, WidgetEvent::MarkAsPostedToRemoteProcess() call in ParamTraits<mozilla::WidgetEvent>::Write() didn't work as expected.
MozReview-Commit-ID: DdafsbVfrya
--HG--
extra : rebase_source : 94205f3a7b36455c3c9f607c35866be033e627c1
Currently, we have 2 bool flags (and optional 2 bool flags with related purpose) for managing propagation state between parent process and remote process. However, it's really complicated. Actually, setting these flags and referring the flags is usually follow explanation.
So, for making simpler, WidgetEvent and BaseEventFlags should have some utility methods for making them as self documented code.
This patch moves WidgetKeyboardEvent::mIsReserved to BaseEventFlags::mIsReservedByChrome. That allows us to manage the cross process event propagation state in same place.
MozReview-Commit-ID: IXEDQJ4GpAZ
--HG--
extra : rebase_source : 5b63ac4f1d15e40e8bfc88423e336de28caa8ab6
I don't bother to label the runnables in the parent process being fired by
VisitedQuery, as we are not planning to perform scheduling in the parent process
if I remember correctly. It would be possible to label those runnables as well.
This also adds a mSeen boolean to the mObservers array, to fix a race caused
when a link is being registered as an observer between NotifyVisited and
NotifyVisitedForDocument being run.
MozReview-Commit-ID: EosNOu62fEV
This allows a bunch of other things to be removed too, including
PluginModuleParent::mSurrogateInstances,
PluginModuleChromeParent::sInstantiated, and NS_PLUGIN_INIT_PENDING.
The patch also removes the AsyncPluginInit crash annotation.
--HG--
extra : rebase_source : cadb1d215fd93051c9032ea0a1fb6f1d2fb80c6d
We should not let the ppm to do work before the first paint in a new cp. This patch
makes sure that we only let the ppm spawn a new process after the last process reached
an idle state AND the main process becomes idle too. r=mrbkap
Most of the changes in this patch are just using the explicit
constructor from gfx::IntSize to gfx::Size, since gfxSize did
that implicitly but gfx::Size doesn't.
MozReview-Commit-ID: CzikGjHEXje
--HG--
extra : rebase_source : 9d19977f2a774d9a2a653db923553a6c2e06f82a
The problem is, only when requesting IME to commit or cancel composition is handled synchronously, TabParent does not send the dispatched eCompositionCommit(AsIs) event to the remote process. Therefore, TabParent (and ContentCacheInParent) never receives the message from the remote process.
This patch makes TabChild notifies TabParent of eCompositionCommitRequestHandled special event message after TabChild dispatches eCompositionCommit into the DOM tree. Then, ContentCacheInParent should decrease mPendingCompositionCount and mPendingEventsNeedingAck as usual composition event messages.
MozReview-Commit-ID: 7ec5HPiE687
--HG--
extra : rebase_source : a9366abf6f8feec2d6ac639fd37f5b5c6ddd9586
TextComposition in the main process is destroyed when the main process sends eCompositionCommit(AsIs) to focused remote process. Therefore, ContentCacheInParent::mCompositionPendingCount is never 2 or more now.
It may cause ContentCacheInParent::Assign() setting older composition's start offset to current composition's start offset in the main process.
For making uplift the following patch easier, the wrong patch should be backed out first.
MozReview-Commit-ID: IHWc7qZBQtc
--HG--
extra : rebase_source : d3936fa82ed670217b711d15bbb0201a8741501b
