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
nsIIOService based events when used via SpecialPowers in mochitests
combined with the preloaded browser in the same process can cause
IsSafeToRun() assertion in SchedulerGroup.h:81. To avoid that we make sure that
previous tests in the suit do not create a preloaded browser. This cannot happen
in a real life scenario.
This part is perma failing on OSX and I guess on windows it only passed
because we have never got to that part because of the poorly written async
calls in the test that we never wait for to complete.
Currently Gecko treats 'auto' component value as zero for animation.
MozReview-Commit-ID: JBvTFzDw7Xy
--HG--
extra : rebase_source : 618e756bbbb66759eea50a8004740e737f8a94e1
Currently Gecko treats 'auto' component value as zero for animation.
<!-- Please describe your changes on the following line: -->
https://bugzilla.mozilla.org/show_bug.cgi?id=1387951
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
Source-Repo: https://github.com/servo/servo
Source-Revision: e0b834033d857b08985fc84e676fac636a8495dc
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c4ba04702afbd72d77f23c1b8163d26998daefb7
Web contetnt processes only need access to a small amount of schema data, but
we currently send them the approximately 600K of full schema data that is
mostly useless to them.
This patch limits the schema data sent to web content processes to what they
actually need, and sends the rest only to extension content processes.
MozReview-Commit-ID: 6G0LThNTOu1
--HG--
extra : rebase_source : 36672ad6323e6466bba3e463fa4f0a16e3fd9090
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
These getters are checked very rarely, and not at all in most sessions. They
don't justify the overhead of adding lazy getters at startup.
MozReview-Commit-ID: 9XVlLapNJCE
--HG--
extra : rebase_source : edff8e878528952aeec851203edaa4d41e37e24d