I also tried to avoid this change but, again, given the number of times I was
repeating the same pattern of defining a static method just to forward a
callback to an instance method, decided it was probably necessary. Without an
easy way to do this, people are more likely to register observers rather than
callbacks, for which we'll wind up paying a continued memory and performance
penalty.
This patch adds a helper which creates a type-safe preference callback
function which forwards calls to an instance method on its closure object.
The implementation is somewhat complicated, mainly due to the constraint that
unregistering a callback requires passing the exact same function pointer that
was used to register it. The patch achieves this by creating the callback
function as a template, with the method pointer as a template parameter. As
long as the Register and Unregister calls happen in the same translation unit,
the same template instance is guaranteed to be used for both.
The main difficulty is that, until C++ 17, there's no way match a value as a
template parameter unless you know its complete type, or can at least compute
its complete type based on earlier template parameters. That means that we
need a macro to extract the type of the method, and construct the template
with the full set of explicit parameters.
MozReview-Commit-ID: 10N3R2SRtPc
--HG--
extra : rebase_source : 7d0a8ddeb77e01d4a6f421459514e93bc0875598
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
Preference callbacks consume a non-trivial amount of memory, which adds up
fast given the number of callbacks we register.
Many of our consumers, however, register a large number of callbacks with the
same function and closure object, but different preference names or prefixes.
Since our callback matching is nothing more complicated than iteration over
all of our registered callbacks, there's nothing that prevents us from
combining all of these into a single callback, with an array of preferences
rather than a single string.
And since we already allocate an extra 8 bytes for each callback object, we
can add a variant tag without increasing our allocation size.
MozReview-Commit-ID: I497lWfMUp3
--HG--
extra : rebase_source : bac374d9a590c325728551d1669ebc6ef8ca3884
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.
Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
looked for a PAC file at http://wpad/wpad.dat
This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.
The high-level components of this patch are:
* nsIDHCPClient.idl - this is an interface which has been defined for querying the
DHCP server.
* nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
thread. The class ExecutePACThreadAction has been augmented to include an
instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
file) back to the nsPACMan object.
* nsProtocolProxyService.cpp
Minor changes to reflect the fact that the PAC URL not being set does not always
mean there is no PAC to be used; instead it could be in the process of being
detected.
* TestPACMan.cpp
This is a new file, and tests only the DHCP auto-detect functionality.
Some tests use multiple threads, as they test the non-blocking proxy detection.
* DHCPUtils.cpp
A class containing the main logic for querying DHCP.
* WindowsNetworkFunctionsWrapper.cpp
A very thin wrapper around the Windows API calls needed by DHCPUtils.
This class was introduced so it could be mocked out in tests.
* nsWindowsDHCPClient.cpp
* An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
most logic is implemented in DHCPUtils.
* TestDHCPUtils.cpp
Tests for DHCPUtils and nsWindowsDHCPClient
MozReview-Commit-ID: 4xFQz3tOLEx
--HG--
extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
The preference storage in the shared memory snapshot is much more compact than
the dynamic hashtable, and is already mapped in memory, so there's no need to
keep the full hashtable in memory in the parent process after the snapshot is
created.
This patch empties the hashtable and the name string arena after the snapshot.
It also removes the accounting for preferences which have changed after init,
since those are, by definition, exactly the set of entries in the dynamic
hashtable.
MozReview-Commit-ID: L6VGq2z4foH
--HG--
extra : intermediate-source : 6c72dc1bff88e81f6c754b0971a44b9592d17ee1
extra : absorb_source : 321a2ac3a2d26bbe089c2183e25fccc85d8689f3
extra : source : 599895de063ef005dbd34847db9ee555410a878f
extra : histedit_source : 5905f462ea3d1c935addbe847e53a7d8589f6f38
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : intermediate-source : 7f4cc96fae1212cb2220770ac7311b9cc51af744
extra : absorb_source : 7c71a5994c26c2a1e34b291947a49ac5b3d633cb
extra : source : dc7ec17179d1961d91b897cec9f409786363ec9e
extra : histedit_source : f7c7a935e72af65446c2abc502744a066a6e2ae5%2C5cd3235724af3e5f22b772de171cea735ec4c047
This patch changes our preference look-up behavior to first check the dynamic
hashtable, and then fall back to the shared map.
In order for this to work, we need to make several other changes as well:
- Attempts to modify a preference that only exists in the shared table
requires that we copy it to the dynamic table, and change the value of the
new entry.
- Attempts to clear a user preference with no default value, but which also
exists in the shared map, requires that we keep an entry in the dynamic
table to mask the shared entry. To make this work, we change the type of
these entries to None, and ignore them during look-ups and iteration.
- Iteration needs to take both hashtables into consideration. The
serialization iterator for changed preferences only needs to care about
dynamic values, so it remains unchanged. Most of the others need to use
PrefsIter() instead.
MozReview-Commit-ID: 9PWmSZxoC9Z
--HG--
extra : intermediate-source : b4f9178f132de2b5f7064df9a9e1b489ea6576c3
extra : absorb_source : 57fd90ea8195adff9d314b813e94dc643fd085e4
extra : source : 5051f15fc2005667cfe76ccae0afb1fb0657c103
extra : histedit_source : 2ebf0e90a5e1b65795b20e9269def7cbbf2d1f11
Since lookups in the snapshotted hashtable are currently O(log n) rather than
O(1), they're expected to be slightly more expensive than the previous
purely-dynamic lookups.
In general, I expect this not to be a major issue. The main concern is pref
cache lookups while initializing the database. Initialization in the parent
process will still always use only a dynamic hashtable, so the performance
characteristics there won't change.
In the child process, though, we'll still need to notify observers of
preferences in the snapshot when they have user values, which could require
any number of lookups at startup (though in practice probably will not).
This patch solves that problem by caching the wrapper for the current known
preference value when dispatching callbacks, and optimizing lookups for that
value when it is present.
MozReview-Commit-ID: 2CAn0rM0bE9
--HG--
extra : intermediate-source : 8eff817d2f7e07409269899c048a9091220dec07
extra : absorb_source : 2609b4d9d1d994e19f884de1d1fba38347d35729
extra : source : faef4df47b2089592df7637f5b8f4ae193e98046
extra : histedit_source : b8a1e41ac70ad3eea354c375fb5f6813c0284a0d
For memory efficiency in content processes, we need to be able to store
changed preferences in a separate dynamic hashtable when their values don't
match the snapshot values.
That makes iteration over the full set of preferences somewhat more
complicated, since not only do we need to iterate over two tables, but we also
need to ignore preferences in the snapshot table if they also exist in the
dynamic hashtable.
This patch solves that problem by adding an iterator helper which iterates
over values in both tables, and skips values in the static table if they also
exist in the dynamic table.
In order to support completely deleting preferences that exist in the base
table, it also ignores all dynamic entries with the None type, so that they
can completely mask deleted base table values.
MozReview-Commit-ID: LCIwyPJMByj
--HG--
extra : intermediate-source : f9362cf1add47c2f62529e42764ed6088d274170
extra : absorb_source : fdaf890e85af43271cffd2371cf6fbf408c6cc50
extra : source : d344247b870668f53fa645e72bda4bb4309346c8
extra : histedit_source : 6cd565727eff617eeba386b563477ce4d4bfbd0a
The in-memory format of shared-memory preferences is significantly different
from the format used by dynamic preferences, which means that we need
different classes to access their properties.
Virtual classes would be a potential solution to this problem, but I don't
think the performance characteristics would be acceptable for preferences
code. And since the wrapper classes used for static prefs are temporary, they
would add the additional snag of figuring out how to keep a valid pointer
alive.
So, instead, this patch adds a wrapper class that can access either type of
preference, based on known type flags in a Variant. It also moves some of the
logic for deciding which preference value to return to the wrapper, so that it
doesn't need to be duplicated for each representation.
MozReview-Commit-ID: LameIIbYcD3
--HG--
extra : intermediate-source : ce379eaab17905f39f1665c3e40f683ebd3f8824
extra : absorb_source : eb5ed3380613e070eff5f9c9501e2640a6d398f9
extra : source : 83d98ea5ebaccded8a20929c0f3316e5618f1f76
extra : histedit_source : 634d033608f72294f6fc34d4449fe0f003758c74
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : intermediate-source : 46a6f9d0773ba2d756d8801cee79bfa994165d44
extra : absorb_source : a725a095946946797fd4f3abe6461e810b15d899
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : 958212e804df7f9e1be6af182e73edc956b9a576
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : intermediate-source : 434106f1b75e3ba900912f261bd22a1b7f5c931d
extra : absorb_source : 647ad37590448ad3c1eb8eb512bf671f262fa96e
extra : source : 68bb03c63b3cee1d47cbddfd3abf919f5783c04b
extra : histedit_source : 2228a9f8395929f5072a3c5ebda6ae3221e4a62d
Once the majority of preferences are stored in a read-only shared map, it
won't be possible to modify the access counts in their entries. Which means we
need a separate map for the access counts.
Fortunately, this code is only active in debug builds, so it shouldn't affect
release users. And the net impact on memory usage of this patchset will still
be decidedly downward.
MozReview-Commit-ID: EuLXlMQJP1M
--HG--
extra : intermediate-source : c490838c8329f6b0c21fa57ef078c44bf7a9ba8d
extra : absorb_source : 37a0f7a5fecba6c28bd6ce30644543c6d60ac823
extra : source : 4a8fbb472c91f13554cac3d0ea638cf9f368ff11
extra : histedit_source : 0e5a5f1cded97bcc959be15aa7194c017fd7efcc%2Cc0ae2011b9b40e6445ee366303f8ec4bb10cc87b
The preference storage in the shared memory snapshot is much more compact than
the dynamic hashtable, and is already mapped in memory, so there's no need to
keep the full hashtable in memory in the parent process after the snapshot is
created.
This patch empties the hashtable and the name string arena after the snapshot.
It also removes the accounting for preferences which have changed after init,
since those are, by definition, exactly the set of entries in the dynamic
hashtable.
MozReview-Commit-ID: L6VGq2z4foH
--HG--
extra : source : 599895de063ef005dbd34847db9ee555410a878f
extra : histedit_source : a3bcc573e29a60a61abaa1b2cc6daa87d6b1a946
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : source : dc7ec17179d1961d91b897cec9f409786363ec9e
extra : histedit_source : 285a99038c6731fed427cd8bc783b65f56e34ebb
This patch changes our preference look-up behavior to first check the dynamic
hashtable, and then fall back to the shared map.
In order for this to work, we need to make several other changes as well:
- Attempts to modify a preference that only exists in the shared table
requires that we copy it to the dynamic table, and change the value of the
new entry.
- Attempts to clear a user preference with no default value, but which also
exists in the shared map, requires that we keep an entry in the dynamic
table to mask the shared entry. To make this work, we change the type of
these entries to None, and ignore them during look-ups and iteration.
- Iteration needs to take both hashtables into consideration. The
serialization iterator for changed preferences only needs to care about
dynamic values, so it remains unchanged. Most of the others need to use
PrefsIter() instead.
MozReview-Commit-ID: 9PWmSZxoC9Z
--HG--
extra : source : 5051f15fc2005667cfe76ccae0afb1fb0657c103
extra : histedit_source : 28f2216b8c1e9d08ed9b2c03910d4b8434e55421
Since lookups in the snapshotted hashtable are currently O(log n) rather than
O(1), they're expected to be slightly more expensive than the previous
purely-dynamic lookups.
In general, I expect this not to be a major issue. The main concern is pref
cache lookups while initializing the database. Initialization in the parent
process will still always use only a dynamic hashtable, so the performance
characteristics there won't change.
In the child process, though, we'll still need to notify observers of
preferences in the snapshot when they have user values, which could require
any number of lookups at startup (though in practice probably will not).
This patch solves that problem by caching the wrapper for the current known
preference value when dispatching callbacks, and optimizing lookups for that
value when it is present.
MozReview-Commit-ID: 2CAn0rM0bE9
--HG--
extra : source : faef4df47b2089592df7637f5b8f4ae193e98046
extra : histedit_source : 3af498eac94f481523e86c31b9c2b3e55b3cd1fb
For memory efficiency in content processes, we need to be able to store
changed preferences in a separate dynamic hashtable when their values don't
match the snapshot values.
That makes iteration over the full set of preferences somewhat more
complicated, since not only do we need to iterate over two tables, but we also
need to ignore preferences in the snapshot table if they also exist in the
dynamic hashtable.
This patch solves that problem by adding an iterator helper which iterates
over values in both tables, and skips values in the static table if they also
exist in the dynamic table.
In order to support completely deleting preferences that exist in the base
table, it also ignores all dynamic entries with the None type, so that they
can completely mask deleted base table values.
MozReview-Commit-ID: LCIwyPJMByj
--HG--
extra : source : d344247b870668f53fa645e72bda4bb4309346c8
extra : histedit_source : bb670afc815f3953ccadebddd04962836569b281
The in-memory format of shared-memory preferences is significantly different
from the format used by dynamic preferences, which means that we need
different classes to access their properties.
Virtual classes would be a potential solution to this problem, but I don't
think the performance characteristics would be acceptable for preferences
code. And since the wrapper classes used for static prefs are temporary, they
would add the additional snag of figuring out how to keep a valid pointer
alive.
So, instead, this patch adds a wrapper class that can access either type of
preference, based on known type flags in a Variant. It also moves some of the
logic for deciding which preference value to return to the wrapper, so that it
doesn't need to be duplicated for each representation.
MozReview-Commit-ID: LameIIbYcD3
--HG--
extra : source : 83d98ea5ebaccded8a20929c0f3316e5618f1f76
extra : histedit_source : b3fc33ea04357e15323c7bcb1d02e73c1a9b0c76
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : dc1c7c8015e0443eed218f826fda9f5b38b3e062%2C4cfa2f90104ca3e907607d884ac86f73ad4995bf
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : source : 68bb03c63b3cee1d47cbddfd3abf919f5783c04b
Once the majority of preferences are stored in a read-only shared map, it
won't be possible to modify the access counts in their entries. Which means we
need a separate map for the access counts.
Fortunately, this code is only active in debug builds, so it shouldn't affect
release users. And the net impact on memory usage of this patchset will still
be decidedly downward.
MozReview-Commit-ID: EuLXlMQJP1M
--HG--
extra : source : 4a8fbb472c91f13554cac3d0ea638cf9f368ff11
The preference storage in the shared memory snapshot is much more compact than
the dynamic hashtable, and is already mapped in memory, so there's no need to
keep the full hashtable in memory in the parent process after the snapshot is
created.
This patch empties the hashtable and the name string arena after the snapshot.
It also removes the accounting for preferences which have changed after init,
since those are, by definition, exactly the set of entries in the dynamic
hashtable.
MozReview-Commit-ID: L6VGq2z4foH
--HG--
extra : rebase_source : d4ba3b6a0ae3d46cf797fd6aaf4502d7a74f49c9
extra : absorb_source : e8b2648578a880d43a5a3a075e60ce1433c737ce
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : rebase_source : 93cad19e27d3aaf5d4cad358cdebd6d80b76f668
extra : absorb_source : 06cb8911c92b66f8863b5e184d88b923cdbd6adc
This patch changes our preference look-up behavior to first check the dynamic
hashtable, and then fall back to the shared map.
In order for this to work, we need to make several other changes as well:
- Attempts to modify a preference that only exists in the shared table
requires that we copy it to the dynamic table, and change the value of the
new entry.
- Attempts to clear a user preference with no default value, but which also
exists in the shared map, requires that we keep an entry in the dynamic
table to mask the shared entry. To make this work, we change the type of
these entries to None, and ignore them during look-ups and iteration.
- Iteration needs to take both hashtables into consideration. The
serialization iterator for changed preferences only needs to care about
dynamic values, so it remains unchanged. Most of the others need to use
PrefsIter() instead.
MozReview-Commit-ID: 9PWmSZxoC9Z
--HG--
extra : rebase_source : 054f4dcd534b41da889304c3c6d3365d56e8edda
extra : absorb_source : de81199e174f2d3604c803a5c016ba2f3baf3558
Since lookups in the snapshotted hashtable are currently O(log n) rather than
O(1), they're expected to be slightly more expensive than the previous
purely-dynamic lookups.
In general, I expect this not to be a major issue. The main concern is pref
cache lookups while initializing the database. Initialization in the parent
process will still always use only a dynamic hashtable, so the performance
characteristics there won't change.
In the child process, though, we'll still need to notify observers of
preferences in the snapshot when they have user values, which could require
any number of lookups at startup (though in practice probably will not).
This patch solves that problem by caching the wrapper for the current known
preference value when dispatching callbacks, and optimizing lookups for that
value when it is present.
MozReview-Commit-ID: 2CAn0rM0bE9
--HG--
extra : rebase_source : 4a7e9611efe5b554309df18f7b18ba9c807b72b2
extra : absorb_source : 185442bd69d616c2d2512df954dde7d1b54f2c30
For memory efficiency in content processes, we need to be able to store
changed preferences in a separate dynamic hashtable when their values don't
match the snapshot values.
That makes iteration over the full set of preferences somewhat more
complicated, since not only do we need to iterate over two tables, but we also
need to ignore preferences in the snapshot table if they also exist in the
dynamic hashtable.
This patch solves that problem by adding an iterator helper which iterates
over values in both tables, and skips values in the static table if they also
exist in the dynamic table.
In order to support completely deleting preferences that exist in the base
table, it also ignores all dynamic entries with the None type, so that they
can completely mask deleted base table values.
MozReview-Commit-ID: LCIwyPJMByj
--HG--
extra : rebase_source : 833abea0620f75410f9922e5d4b5cf36b84e9e50
extra : absorb_source : 89690c674120eb99ad25804408b1c3864c7b1fc8
The in-memory format of shared-memory preferences is significantly different
from the format used by dynamic preferences, which means that we need
different classes to access their properties.
Virtual classes would be a potential solution to this problem, but I don't
think the performance characteristics would be acceptable for preferences
code. And since the wrapper classes used for static prefs are temporary, they
would add the additional snag of figuring out how to keep a valid pointer
alive.
So, instead, this patch adds a wrapper class that can access either type of
preference, based on known type flags in a Variant. It also moves some of the
logic for deciding which preference value to return to the wrapper, so that it
doesn't need to be duplicated for each representation.
MozReview-Commit-ID: LameIIbYcD3
--HG--
extra : rebase_source : bf986b6008123661547949f615c8416403321835
extra : absorb_source : e86aae959325a9c3198e0259468a47a656739278
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : rebase_source : f5de7462438e33cf4983be3fcef3c781c25ec492
extra : absorb_source : 9f9861546fc0b11333e575bb3c164dfe07575d99
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : rebase_source : e7cb96dd52380f2ed2fbd79b4e157e4efab65cb0
extra : absorb_source : ed95ed85388875353458eb65e41727e606ebf097
Once the majority of preferences are stored in a read-only shared map, it
won't be possible to modify the access counts in their entries. Which means we
need a separate map for the access counts.
Fortunately, this code is only active in debug builds, so it shouldn't affect
release users. And the net impact on memory usage of this patchset will still
be decidedly downward.
MozReview-Commit-ID: EuLXlMQJP1M
--HG--
extra : rebase_source : 6a32f03c37622093c67e7ee7a0e935d1e63c4fc8
- Refactored gfxVROpenVR to use gfxVRExternal interface from the
VR Service. Existing gfxVROpenVR left in place (for now) to
allow VR service to be enabled or disabled by pref.
- The VR service, containing gfxVROpenVR, is to run in-process within
its own thread first, then to be later moved to its own process.
- Fixed periodic immersive mode flicker that occured due to HMD pose and
HMD state being separately sampled from the Shmem. It was possible
to advance a frame without also getting an updated pose if a dirty
copy of the shmem was detected.
MozReview-Commit-ID: IvpJErmi5kF
--HG--
extra : rebase_source : 0e21d3414a13dc514c3035f2bd5f6adc365b465d
