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
This reduced the additional string duplication that we currently do every time
we add a preference observer.
It changes the string that we store in the observer objects to be absolute,
rather than relative to the branch, but keeps the semantics the same, by
resolving the full preference name in the places we were previously matching
by relative string.
This actually has the effect of simplifying a lot of code, since the absolute
preference name is usually what we want.
MozReview-Commit-ID: 10WjHb0tNGB
--HG--
extra : rebase_source : b3cb0ba103fc239e42459e77cd389db0b5ecde18
Most preference callbacks use literal strings for their domain filters, which
means that there's no need to make copies of them at all. Currently, however,
every preference observer node makes a separate heap-allocated copy of its
domain string.
This patch switches the domain string storage to nsCString instances, which
dramatically reduces the amount of unnecessary copies, at the expense of
making the callback nodes slightly larger.
MozReview-Commit-ID: 8NA3t2JS2UI
--HG--
extra : rebase_source : 628ad9af65cec16fb8be0c8dddc608b5ee5602e2
Summary:
This will allow to be called from the MediaCapabilities taskqueue if we find that a decoder won't be hardware accelerated.
It is still assumed that Benchmark::Init() was called at least once on the main thread.
Depends on D1628
Tags: #secure-revision
Differential Revision: https://phabricator.services.mozilla.com/D1767
Test that a video which tries to autoplay via either a play() call or via
an autoplay attribute:
* Plays when it has a pre-existing "allow" autoplay-media permission.
* Is blocked when it has a pre-existing "block" autoplay-media permission.
* Plays when it doesn't have a pre-existing autoplay-media permission and
"allow" is pressed on the door hanger.
* Is blocked when it doesn't have a pre-existing autoplay-media permission and
"block" is pressed on the door hanger.
MozReview-Commit-ID: CpftV6RQbtU
--HG--
extra : rebase_source : a9c38a7e7071e3ebd34f10175f4f22cd84c4c303
Dropbox has fixed the bug by their side. Therefore, we can drop
"paper.dropbox.com/doc" from the blacklist now.
MozReview-Commit-ID: 9nWdmDQ0sSY
--HG--
extra : rebase_source : 5a348f879857a88a33e52753cc9b1d3f1ecc0e11
Feature is mature and doesn't need pref.
In fact, it was not used in code anymore, only in tests.
MozReview-Commit-ID: AbH8OCiksDa
--HG--
extra : rebase_source : b9a7d18b3c1b948f213632a16d2152f80d676068
The new pref is "network.dns.resolver-thread-extra-idle-time-seconds"
The default is 60 seconds. This means that threads will stay idle for an extra 60 seconds, after which they are shutdown.
Setting the pref to 0 would preserve the behaviour before the threads were swiched to use nsThreadPool - meaning that they would be shutdown immediately after ThreadFunc completes.
Setting the pref to -1 would keep the threads alive forever.
MozReview-Commit-ID: CoUB5gan4MR
--HG--
extra : rebase_source : 7b444789eebaf43c939ce9d7153218c4cd594b65
The 'all' shorthand has shipped a long time ago, so this pref is not needed
anymore.
MozReview-Commit-ID: GND8qSVAfCG
--HG--
extra : rebase_source : 10708e749911fa95554ed423a5782db61df67cd0
Summary:
This patch adds the infrastructure to move Activity Stream (about:newtab, about:home,
and about:welcome) into its own special content process - the privileged content
process. This feature of running Activity Stream in the privileged content process
is disabled by default. (See "browser.tabs.remote.separatePrivilegedContentProcess"
preference.) We can deal with other about: pages in a follow-up.
Reviewers: mconley
Tags: #secure-revision
Bug #: 1469072
Differential Revision: https://phabricator.services.mozilla.com/D1731
MozReview-Commit-ID: 5gIrP4LxcIt
--HG--
extra : rebase_source : d43c411ae60aad3d5a3a496e6729de0b547b4acd
- Introduced the io.activity.enabled pref, so IOActivityMonitor can run without a timer
- Added IOActivityMonitor::NotifyActivities() to trigger notifications manually
- Added ChromeUtils.requestIOActivity() so we can trigger it via JS
MozReview-Commit-ID: 9JA2rLaM496
--HG--
extra : rebase_source : e473a7b0ec7c231ab321846c5ddcc4d6a88d7245
This pref can be used by users to force-disable WebRender. It is
recorded in the telemetry environment so we can get a sense of how many
people are setting this pref.
MozReview-Commit-ID: yZSN44NMvD
--HG--
extra : rebase_source : d355236773f63da0f6acb5341f4ae6a88cd0a488
- Introduced the io.activity.enabled pref, so IOActivityMonitor can run without a timer
- Added IOActivityMonitor::NotifyActivities() to trigger notifications manually
- Added ChromeUtils.requestIOActivity() so we can trigger it via JS
MozReview-Commit-ID: 9JA2rLaM496
--HG--
extra : rebase_source : 0a92195b6b8314383c63de4b2bb1dfe033c40e9f
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
Now uses StaticPrefs instead of DOMPrefs, and how we count dispatches for Workers.
MozReview-Commit-ID: DTumwcI5bG
--HG--
extra : rebase_source : 0cf5312e714fb260c01df647b2cd1fcc28ffc415
Generalizes NetworkActivity so it can be used for sockets but also disk files.
The host/port data becomes a single location string prefixed with socket://
or file:// and we're not using the FD as the identifier anymore.
IOActivityMonitor is now used in three places:
- nsFileStreams for plain files
- TelemetryVFS for sqlite files
- nsSocketTransport & nsUDPSocket for UDP & TCP sockets
MozReview-Commit-ID: GNu5o400PaV
--HG--
rename : netwerk/base/NetworkActivityMonitor.cpp => netwerk/base/IOActivityMonitor.cpp
rename : netwerk/base/NetworkActivityMonitor.h => netwerk/base/IOActivityMonitor.h
rename : netwerk/base/nsINetworkActivityData.idl => netwerk/base/nsIIOActivityData.idl
extra : rebase_source : 55a1c51b261ffbe16f88671d55445d1b0d9106b6
This pref was used to enable the building of nsDisplayLayerEventRegions
items without APZ, so that we could test it in isolation. However, we no
longer need to do so, and these display items are going to be deleted
anyway, so we can remove this pref.
MozReview-Commit-ID: LJVcFafCKyS
--HG--
extra : rebase_source : 76d8eeca8dca4ea88b8226bbe6b829dbc40e03e4
This removes the gfx.webrender.hit-test pref, assumes a value of true
everywhere it is used, and deletes all the resulting dead code.
Some gtests were setting this pref to false, and they are now updated to
set gfxVars::UseWebRender to false instead, which has the desired effect
of using the non-WR hit-testing codepath in APZ. (The data needed for
this codepath is set up by the gtests themselves).
MozReview-Commit-ID: 9ljDr8eEnv1
--HG--
extra : rebase_source : fbc321861428e7bb0bf7ab811935b682785debdc
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : 59e4a6ced7d14d2a01c0b79e944078ea84cae523
Atomic<bool> is implemented in terms of AtomicBase<uint32_t>, because that way
you don't need to depend on atomic 1-byte operations. That means that the rust
bindgen sees it as a u32, not a bool.
It's a bit concerning that the rust code seems to be doing an unsynchronized
read here, but given this is a RelaxedAtomic, that's probably ok.
And use the C++ ErrorReporter only to actually output errors.
ErrorReporter was so complicated because well, it was always enabled and had to
do a bunch of caching to not be (more) slow.
But since bug 1452143 it's disabled by default, so we can simplify this setup a
lot.
Also while at it make the error reporting pref a static pref so that we don't
mutate globals from CSS parsing unless we're actually reporting errors.
MozReview-Commit-ID: AuIyvJwt7AU
remember the milk has fixed the bug of Closure with updating their Closure
version. Therefore, we don't need to avoid using strict keypress event
behavior on it.
MozReview-Commit-ID: 4YfMXY7Zf6g
--HG--
extra : rebase_source : 363bcacf06c09931e266cef44584e40de0be8f40
It has greatly regressed with recent AMD drivers, providing worse performance than the software decoder under most circumstances.
MozReview-Commit-ID: Jtabi1qhoYF
--HG--
extra : rebase_source : 555e3bfdad18753079ccdcdd10261d68bbdaaad1
We can hit the limit very easily when writing javascript bytecode as alternative data to the cache entry because all data is written at once but CacheFileOutputStream splits it into chunks which are then written on a backgound thread. 40MB was chosen because bytecode is usually 4x-10x larger than the original data, so it can occupy most of the cache entry which is limited to 50MB.
This patch defined a new ExtensionStorageIDB module, which provides the
same "internal" API currently provided by ExtensionStorage and uses
IndexedDB as its backend (instead of the JSONFile used as the backend
provided by ExtensionStorage).
MozReview-Commit-ID: DsvPudExcyr
--HG--
extra : rebase_source : c1046955a3aaf226bba9d1cd7aacd86808c536a7
This patch defined a new ExtensionStorageIDB module, which provides the
same "internal" API currently provided by ExtensionStorage and uses
IndexedDB as its backend (instead of the JSONFile used as the backend
provided by ExtensionStorage).
MozReview-Commit-ID: DsvPudExcyr
--HG--
extra : rebase_source : f67691b7775cd8961f3152f1fa8becee7eaddb2e
Currently, if the "layout.accessiblecaret.allow_script_change_updates"
pref is false, we always hide accessible carets when the selection
changes due to JS calls (e.g. setSelectionRange(0, 1)). If the pref is
true, instead, we update the accessible carets if they are already
visible. In either case, we never show the carets if they're invisible.
However for testing purposes, it's useful to make it so we do try to
show the carets if they're invisible. This patch replaces that pref with
the new integer pref "layout.accessiblecaret.script_change_update_mode",
which can be 0 or 1, which correspond to the old pref, or the value 2,
which introduces this new behavior of always showing the carets.
MozReview-Commit-ID: Bf1gPpIzcyb
--HG--
extra : rebase_source : 5eaba6c18d800da425d5e21f61af880678d7fe3c
We can't remove navigator.javaEnabled() entirely because that would break any web content that tries to call the function.
MozReview-Commit-ID: KIOBrZuMu9r
--HG--
extra : rebase_source : 112ec5308d59e8d12a8ea540784ea157e575d09c
extra : intermediate-source : e9b145757c2f27440749408d9de31df7b5d60ff8
extra : source : 5fe4a7a8723bbd9cd954905cbf3937f45706d660
extra : histedit_source : a62c9571a53a834ef15778a01cb993d7e8dc3daa
The security.allow_chrome_frames_inside_content pref was added to support
XUL extension compat after the hiddenWindow special case was removed in
Bug 1145470. Since we don't need to support that use-case anymore, this
changeset backs out the change that relanded the special case with the pref.
MozReview-Commit-ID: 4keMEIQvt1Y
--HG--
extra : rebase_source : 642464c622414017861dced9fbeb0c3500d43430
It's been removed for a while on Nightly without any known regressions. This
gives us a full beta cycle of telemetry and two nightly cycles without the API
before shipping.
This only removes the API, followup work will replace serialization by Servo's,
and remove the remaining DOM interfaces.
MozReview-Commit-ID: 2m1taYg5xEr
This ensures that only people with qualified hardware can flip prefs to
enable WebRender on beta and release. Nightly users will still be able
enable WebRender on unqualified hardware.
MozReview-Commit-ID: E5sgzZhuX4p
--HG--
extra : rebase_source : a4e85e71e4d85b5d9f1e17c1413ca9690349f75a
The JS engine has changed the APIs that cooperative scheduling relies
on into immediate crashes. Some users seem to set the prefs, and then
we get a lot of crashes on Nightly. This removes the top-level pref to
save them some grief.
I continue to pass the pref as false to the child process to avoid
weirdness if we somehow we get this far when the parent and child have
different versions.
MozReview-Commit-ID: 3o3yV2efx2r
--HG--
extra : rebase_source : 398c4d77ce3f78f3814ac97882b4a5e3190c44f7
All animated images on a page are currently registered with the refresh
driver and advance with the tick refresh. These animations may not even
be in view, and if they are large and thus cause redecoding, cause a
marked increase in CPU usage for no benefit to the user.
This patch adds an additional flag, mCompositedFrameRequested, to the
AnimationState used by FrameAnimator. It is set to true each time the
current animated image frame is requested via
FrameAnimator::GetCompositedFrame. It is set to false each time the
frame is advanced in FrameAnimator::AdvanceFrame (via
FrameAnimator::RequestRefresh). If it is true when
FrameAnimator::RequestRefresh is called, then it will advance the
animation according to the normal rules. If it is false, then it will
set the current animation time to the current time instead of advancing.
This should not cause the animation to fall behind anymore or skip
frames more than it does today. This is because if
FrameAnimator::GetCompositedFrame is not called, then the internal state
of the animation is advancing ahead of what the user sees. Once it is
called, the new frame is far ahead of the previously displayed frame.
The only difference now is that we will display the previous frame for
slightly longer until the next refresh tick.
Note that if an animated image is layerized (should not happen today) or
otherwise uses an ImageContainer, this optimization fails. While we know
whether or not we have an image container, we do not know if anything is
actively using it.
paper.dropbox.com provides editable and sharable document. Some editing
shortcut keys in it listens to "keypress" events on Firefox. Therefore,
we need to add the URL into the blacklist for Nightly testers.
MozReview-Commit-ID: 3bCrjIzP80v
--HG--
extra : rebase_source : 06420cb6a2a9a511edded9a5133d5d07ab240d61
Most of this module is dead code, intended to convert directory listings into
RDF data sources for a XUL front-end which no longer exists.
Rather than keep the remaining code which still has any effect, I opted to
just replace it with a JS stub, which winds up being much simpler.
MozReview-Commit-ID: CiBpV0mrOo0
--HG--
extra : source : 2ea9f1f5269ed5291275a174a633b23dc92667de
extra : histedit_source : fdc195bff4684a84f610b90c0d9820b860c5ff40
Non functional code.
SourceBuffer.changeType allows to reconfigure a sourceBuffer so that a new codec type or new container format can be fed later.
The new code is placed behind the media.mediasource.experimental.enabled pref.
MozReview-Commit-ID: 5wj6J4uzLbA
--HG--
extra : rebase_source : b6f57246e0a4c856f6365bb0c8ec8d759a770105
framapad.org provides a lot of public Etherpad instances even though only
mensuel.framapad.org is listed by Etherpad's information. Therefore, we should
change the blacklist for avoiding dispatching keypress events strictly from
"mansuel.framapad.org/p/" to "*.framapad.org/p/" to allow any Etherpads in
the subdomains work in Nightly builds.
MozReview-Commit-ID: 9H4oIc2PGal
--HG--
extra : rebase_source : d97bdc89a0a5d2a15c89dd08f995b519fc1ce10c
Shipped since Firefox 48, other browsers have similar impls, and the related
spec has been in CR since a while ago.
The syntax of this property as implemented should be considered to be pretty
stable, so we can remove this pref.
MozReview-Commit-ID: H7lDsdbUamD
--HG--
extra : rebase_source : fda63805d9dea49a55d57153c841426508a882f6
This moves all the tiling prefs into one spot and organizes them a bit. It also fixes a common issue
with `edge-padding` being enabled on windows because it wouldn't be defined in all.js and defaulting
to enabled. Note that `worker-threads` is switched to `-1` by default here instead of just for OSX.
This should have no affect because we don't actually create the threads unless we are tiling, which
only happens right now on OSX.
MozReview-Commit-ID: D8HOs3yv7w0
--HG--
extra : rebase_source : 9b5d2d228af743ea4facd076dfa2f370ea93ebc8
www.remberthemilk.com is a todo app. Its dropdown lists are implemented by
themselves, however, we cannot navigate the dropdown list with ArrowDown
and ArrowUp keys. For now, we should allow to dispatch non-printable key
events in the domain.
MozReview-Commit-ID: 10iMoRZfB4j
--HG--
extra : rebase_source : 312d38a4f95dfe7553a6762507f2f6fc4fba3e9f
This patch set calls a bit deeper in the audio callback thread (down into opus,
in particular).
MozReview-Commit-ID: 6LWACS6V0Yz
--HG--
extra : rebase_source : a61d08b301d86bf2ce5e965295d5a944a0ebc8d8
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: HinC1UevOon
--HG--
extra : rebase_source : cf29f76826cc7728fd36505c8271bf50001c644c
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: HinC1UevOon
--HG--
extra : rebase_source : df2b80fcc03948e54f222e11060e1783f3b95421
Google Inbox also has specific subdomain and it handles shortcut keys with
keypress events on Firefox. So, let's include inbox.google.com into the
blacklist to allow to dispatch non-printable keypress events in it.
MozReview-Commit-ID: 98Ocm2AnAG1
--HG--
extra : rebase_source : 8a0970881079bff5b3a778215b62c430beb31adc
