In case another application is still using the port, and the
handshake with Marionette server is not successful, the
function should return immediately. Otherwise it has to continue
to wait until a successful connection has been made..
MozReview-Commit-ID: CuOMNotmCDP
--HG--
extra : rebase_source : 9772f7b4e08860c4e97ac07fde0b679242f22456
A connection to Marionette server should only be accepted
if the application type equals to 'gecko', and the protocol
version as returned is supported by the client.
MozReview-Commit-ID: LjZCsL4dt8Y
--HG--
extra : rebase_source : 66603c2705f3369c357b69895d536af00e5e8511
To allow more fine-grained failure details when waiting for
a port, raise_for_port has to be used.
MozReview-Commit-ID: 5Anfd9yRVY0
--HG--
extra : rebase_source : 242d5f769c66d40cfa1f02ec3e6abdc4e7adc878
This method has not a single caller and as such doesn't seem to
be necessary anymore.
MozReview-Commit-ID: qhNK3EBc6Q
--HG--
extra : rebase_source : 2978829739f0bc465f98b8f6b727c27a03a42b11
wait_for_port() is defined to return a boolean value, which
makes it impossible to return more detailed information in
case of a connection cannot be established. Further the
raise_for_port() method is a simple wrapper, without any
additional usage.
MozReview-Commit-ID: 2A4sCaEylgP
--HG--
extra : rebase_source : c589cd73332c73e3a7adafcf2ccfc8246013f4ca
Put them in internals/Preferences since it is definitely an internal, and they
have complex interactions with preferences.
Not seen here: updates to Preferences for the recent changes. That's covered in
bug 1406394
MozReview-Commit-ID: 7X0d4ZmHbLw
--HG--
extra : rebase_source : b7b22212e50ee5ead0c53325c380e2568c4dfb9d
Response content should only be fetched whenever it is strictly needed
as it is the response body. A possibly very large string.
So, netmonitor UI should only retrieve it when users select the Response Panel
or do any other action that require having access to it (like "Copy response"
context menu).
MozReview-Commit-ID: CtpJ8PKsCsm
--HG--
extra : rebase_source : f3d7aea2b752377891bef6ea466e140e93fe8b8b
Currently, huge allocations are completely independent from arenas. But
in order to ensure that e.g. moz_arena_realloc can't reallocate huge
allocations from another arena, we need to track which arena was
responsible for the huge allocation. We do that in the corresponding
extent_node_t.
Both functions do essentially the same thing, one having more validation
than the other. We can use a template with a boolean parameter to avoid
the duplication.
Furthermore, we're soon going to require, in some cases, more
information than just the size of the allocation, so we wrap their
result in a helper class that gives information about an active
allocation.
These low level docs are getting out of date and causing confusion. Further,
they are of limited value at this stage anyway.
MozReview-Commit-ID: FSoNniNZjtj
--HG--
extra : rebase_source : fa5e02a771adcae9b0e53bd18c4eb10ebb5315ef
We already remove all change hints down the tree when finding a reframe hint
using ClearServoRestyleFromSubtree in ServoRestyleManager, so this is useless.
MozReview-Commit-ID: 1twx7iPt79x
Source-Repo: https://github.com/servo/servo
Source-Revision: 20ccde9a75e52f3dc7adccf0136f5753deb41158
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4e8d88923fef766a3d9eeca267356ef6962809c6
Henrik Skupin
Chris H-C
Noemi Erli
Emilio Cobos Álvarez
Zibi Braniecki
shindli
Alexandre Poirot
Peter Major
Ionut Goldan
Sebastian Hengst
Margareta Eliza Balazs
Phil Ringnalda
Gabriel Luong
Mike Cooper
Matt Woodrow
Mike Hommey
Tommy Kuo
ffxbld
Andreea Pavel
J. Ryan Stinnett
dluca