Previously we had disabled them in content pages on Nightly and Early Beta,
now we're ready to let this ride the trains in 61.
We're going to land this ahead of Bug 1446470 which is specifically about
url-prefix().
MozReview-Commit-ID: AGDHt1snyjU
--HG--
extra : rebase_source : 7f26f898ff887cd4915d5b5a7bd7c3de0476a803
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds
MozReview-Commit-ID: H5MUJOEkpia
--HG--
extra : rebase_source : 8ebb459445cab23288a6c4c86e4e00c6ee611e34
These statistics will be used by browser tests to analyze frequently accessed
preferences so that we can recommend using preference observers instead.
MozReview-Commit-ID: 9uZnwmjZL4U
--HG--
extra : rebase_source : c8a8e624f06dfff12d8503a7c8299a0051192339
This pref was introduced in case we encountered compatibility issues from
changing the return value of Animation.playState (bug 1412765). Now that the
change to Animation.playState has shipped to release channel without any known
problems we should drop this pref.
MozReview-Commit-ID: CwMWRRtIf6u
--HG--
extra : rebase_source : b26c59a51880406c2b94baad8da2eafeb3ae3202
The compartment-per-addon code was added so that we could segregate at least
some of the code from system-privileged add-ons into tagged compartments, even
when it ran in browser windows. That allowed us to apply certain special
behavior to them, such as enabling e10s shims, and to track some performance
characteristics.
The only remaining chrome-privileged add-ons now are system add-ons controlled
by us, and the shim system and per-compartment performance metrics are gone,
it no longer serves a purpose.
MozReview-Commit-ID: Ap186bWAaqP
--HG--
extra : rebase_source : c5bf81b44dd42b7cebce2784b7dd98480b41b593
We no longer support legacy extensions with e10s shims, and the only remaining
uses that matter are in-tree test harnesses, which have been fixed. This flag
no longer serves a purpose.
MozReview-Commit-ID: EdCNqF4MttN
--HG--
extra : rebase_source : 0fef334354faa7541628614cb964a29faaa9df41
uim is an old IM which uses key snooper to listen to key events rather than
via filter key event API which should be called by applications. It's still
used by Debian 9.x, so, we still need to support this.
Unfortunately, we cannot detect if uim actually uses key snooper because it's
switch by build option of uim. Currently, Debian builds uim as using key
snooper. So, we should assume uim uses key snooper always. On the other
hand, somebody *might* use uim built as not using key snooper, so, let's
decide if uim uses key snooper with new pref,
"intl.ime.hack.uim.using_key_snooper", but its default should be true.
Note that ibus and Fcitx also have the mode to use key snooper (perhaps for
backward compatibility with uim). However, it's not enabled in default
settings and even if it's enabled, Firefox is in whitelist in the default
settings of them for stop using key snooper. Therefore, we don't need to
support key snooper mode for them unless we'll get some requests to
support their key snooping mode.
MozReview-Commit-ID: 6fTsfKrHzvo
--HG--
extra : rebase_source : 8ddf4541db635246e6bb0ddc73b012c9be001c6d
- gfxVRExternal Enables other processes to present
real or simulated VR hardware to Firefox.
- This functionality is disabled by default, under
dom.vr.external.enabled.
- VRDisplayInfo, VRControllerInfo, and associated
structs have been restructured to ensure internal
state is not exposed via shmem interface.
- Some refactoring to convert structs to
POD types, enabling them to be located
in shmem and be memcpy'd.
- Work needed before unpreffing marked
with "TODO" comments.
MozReview-Commit-ID: FbsusbxuoQ8
--HG--
extra : rebase_source : 8a448169c3f47411c705a4d9fd462a1f9363dfd9
extra : amend_source : e6702549527292e2850d16e8f503f0be9848159f
On Android, GeckoEditableSupport has already dispatched eKeyDown event and
eKeyUp event even during composition. I.e., the pref which will be enabled
by bug 354358 has already been set to true only on Android.
On the other hand, GeckoEditableSupport does not dispatch them if content
listens to "input", "compositionstart", "compositionupdate" or
"compositionend". So, different from the other platforms, we need additional
pref to make the new behavior behind pref.
Therefore, this patch adds a new pref,
"intl.ime.hack.on_any_apps.fire_key_events_for_composition", to override
existing "intl.ime.hack.on_ime_unaware_apps.fire_key_events_for_composition"
pref. And sets mKeyCode and mKeyNameIndex of the dummy KeyboardEvents to
NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process.
MozReview-Commit-ID: Fuy0Ir2xiO5
--HG--
extra : rebase_source : c76b613ea186458ebdf0d67f4bc984e8ac5f1041
uim is an old IM which uses key snooper to listen to key events rather than
via filter key event API which should be called by applications. It's still
used by Debian 9.x, so, we still need to support this.
Unfortunately, we cannot detect if uim actually uses key snooper because it's
switch by build option of uim. Currently, Debian builds uim as using key
snooper. So, we should assume uim uses key snooper always. On the other
hand, somebody *might* use uim built as not using key snooper, so, let's
decide if uim uses key snooper with new pref,
"intl.ime.hack.uim.using_key_snooper", but its default should be true.
Note that ibus and Fcitx also have the mode to use key snooper (perhaps for
backward compatibility with uim). However, it's not enabled in default
settings and even if it's enabled, Firefox is in whitelist in the default
settings of them for stop using key snooper. Therefore, we don't need to
support key snooper mode for them unless we'll get some requests to
support their key snooping mode.
MozReview-Commit-ID: 6fTsfKrHzvo
--HG--
extra : rebase_source : 8ddf4541db635246e6bb0ddc73b012c9be001c6d
Adds a PeformanceCounter class that is used in DocGroup and WorkerPrivate
to track runnables execution and dispatch counts.
MozReview-Commit-ID: 51DLj6ORD2O
--HG--
extra : rebase_source : b481c9aa3b735569722bb7472872ec2d22adcb89
For confirming to UI Events spec, we should dispatch "keydown" event and
"keyup" event even during in composition.
This patch makes only Nightly and early Beta start to dispatch those events
during a composition.
MozReview-Commit-ID: 8md7NtSdurJ
--HG--
extra : rebase_source : 2527089ee2844ee6a816ee3afae461275c61c409
Historically we built all our binaries in directories in the objdir, then
symlinked them into dist/bin. Some binaries needed to be copied instead
so that certain relative path lookups work properly, so we resorted to
sprinkling `NSDISTMODE=copy` around Makefiles.
This change makes it so we build PROGRAMs (not any other sort of targets)
directly in dist/bin instead. We could do the same for our other targets
with a little more work.
There were several places in the tree that were copying built binaries to
some other place and needed fixup to match the new location of binaries.
On Windows pdb files are left in the objdir where the program was
originally linked. symbolstore.py needs to locate the pdb file both to
determine whether it should dump symbols for a binary and also to copy
the pdb file into the symbol package. We fix this by simply looking for
the pdb file in the current working directory if it isn't present next
to the binary, which matches how we invoke symbolstore.py.
MozReview-Commit-ID: 8TOD1uTXD5e
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds
MozReview-Commit-ID: H5MUJOEkpia
--HG--
extra : rebase_source : 01c8d16f7d31977eda6ca061e7889cedbf6940c2
Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
This patch doesn't change the functionality, it just splits out the code into
separate functions that are easier to read.
MozReview-Commit-ID: Gx05YCxGgve
--HG--
extra : rebase_source : 3b7250cea630bebf35992bb69e651509c863c1c6
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
This code was originally added to debug the frame visibility code.
However it wasn't architected correctly and makes the compositor use an
untrusted layers id from content. Instead of fixing this I'd rather just
delete it, since it's a big pile of code that is basically a debugging
tool that nobody owns anymore.
MozReview-Commit-ID: nPZqVeYsFp
This retains support for installing unpacked dictionaries, since Hunspell only
supports loading dictionaries from ordinary filesystem paths.
Unpacked extensions are no longer supported on production, except during
development. WebExtensions have no support for the unpacked flag at all, and
specially signed legacy extensions are forbidden from using it, so there's no
point in maintaining support for this install code. Or, more importantly, for
running a nearly complete duplicated set of tests in order to exercise it.
MozReview-Commit-ID: 1fKVgSelJQ8
--HG--
extra : rebase_source : a2e9086a3d050b66eab9c17fff9c2f7189911832
extra : amend_source : da8f6425ec74a824a3d19f13bb4eb51980cd64c1
Early AAAA responses might cause issues on hosts without working native
IPv6 connectivity, of course especially notable in TRR-only mode.
MozReview-Commit-ID: 6ZqE6AKnucH
--HG--
extra : rebase_source : ff42cb8daf941a3fa1f7e783c76d823e879024c3
Sticky prefs are already specifiable with `sticky_pref`, but this is a more
general attribute mechanism. The ability to specify a locked pref in the data
file is new.
The patch also adds nsIPrefService.readDefaultPrefsFromFile, to match the
existing nsIPrefService.readUserPrefsFromFile method, and converts a number of
the existing tests to use it.
MozReview-Commit-ID: 9LLMBJVZfg7
--HG--
extra : rebase_source : fa25bad87c4d9fcba6dc13cd2cc04ea6a2354f51
It optimizes Preferences::IsLocked(), but that function is called fewer than
200 times while starting the browser and opening a range of tabs.
MozReview-Commit-ID: 5q0zS8TSwdu
--HG--
extra : rebase_source : 015c5ebbe28097ef3f02b1062e650df67721f1c3
We have stopped dispatching "keypress" events for non-printable keys
and key combinations for conforming to UI Events and following the
other browsers.
However, this change hits a serious bugs of Google Docs, Google
Spreadsheets and Gmail. Until they will fix their bugs, we should
take back the traditional behavior for keeping Nightly usable for
any Nightly testers.
MozReview-Commit-ID: 9CyEbsFit1S
--HG--
extra : rebase_source : 837288b1fb53121badff4e65094a87cebfe3cfee
I also removed the explanation string in cases where I felt it was obvious.
MozReview-Commit-ID: IyHswX3s23y
--HG--
extra : rebase_source : ee0a4729b486e42bd50edf3d5870368e0aaa2310
The following table shows the effect of this change:
> old 64-bit new 64-bit old 32-bit new 32-bit
> sizeof(CallbackNode) 40 32 20 16
> size when heap allocated 48 32 32 16
This reduces memory usage by about 15--40 KB per process.
MozReview-Commit-ID: 4gXgGI3SiJz
--HG--
extra : rebase_source : d62e0b708024b1d8ececd1d5c295159e751e6727
This isn't compelling on its own, but it's necessary for the next patch.
MozReview-Commit-ID: CFON8DCdGoA
--HG--
extra : rebase_source : 2b219e2a1330923f63af6dae1d8ab5f2428f926f
This shows that the objects themselves are accounting for about 60% of the
callback memory on 64-bit, and the domains are about 40%.
MozReview-Commit-ID: JndlyIvlrGs
--HG--
extra : rebase_source : 7a60203421c3e03d7cbe36614c72ffe674a4bc71
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : 40b29d34e5cc99f9b8e6d5e711a03b9fe9bfa595
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : e455f934e6e6d65d54c122a6cec9f6cabbd5ac78
UI Events declares that keypress event should be fired only when the keydown
sequence produces some characters. For conforming to UI Events and
compatibility with the other browsers, we should stop dispatching keypress
events for non-printable keys.
For getting regression reports, we should enable this new behavior only
on Nightly and early Beta.
MozReview-Commit-ID: 5IIL9huejXH
--HG--
extra : rebase_source : 0abdbe84a50d6fd1b4d52521b92e7513483b197c
image.animated.decode-on-demand.threshold-kb is the maximum size in kB
that the aggregate frames of an animation can use before it starts to
discard already displayed frames, and redecode them as necessary. The
lower it is set to, the less overall memory we will consume at the
expense of execution time for as long as the tab with the animation(s)
above the threshold are kept open.
image.animated.decode-on-demand.batch-size is the minimum number of
frames we want to have buffered ahead of an animation's currently
displayed frame. The decoding will request this number of frames at a
time to maximize use of memory caching. Note that this is related to the
above preference as well; increasing the batch size will in effect raise
what the minimum threshold. This simplifies the logic in patches later
in the series.
For FF59, we disabled WebVR for macOS before allowing it to ride the trains to release. Softvision was unable to verify for QA due to challenges getting a working hardware configuration for macOS VR at SoftVision.
We have since gained approval from the Firefox Release Team to re-enable WebVR for macOS in release for FF60.
Essentially, we need to reverse the changes in bug 1426500 and uplift to FF59/Beta before the next cycle.
--HG--
extra : rebase_source : 1b0c68b130f869f0e71cf2d93db92bb78dddc79b
This patch disables device sensors except orientation by default.
It implements per-sensor prefs to disable orientation, motion, proximity and ambient light
selectively. The patch also makes the pref checks happen at runtime (versus on process
start) using Preferences::AddBoolVarCache.
The patch also removes the related Event constructors also.
MozReview-Commit-ID: EA8ARjjtlkF
--HG--
rename : dom/events/test/test_bug742376.html => dom/events/test/test_deviceSensor.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_disabled_events.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_eventctors_sensors.html
extra : rebase_source : 39da98ac9226ac727f5197d28561b0b762da06f4
Before Firefox 58 we collected extended collection from users on nightly,
aurora, and beta. Then we had to change things (see bug 1406391).
In doing so, we accidentally stopped receiving data from "release candidate"
beta builds. This patch resumes that collection by detecting an RC build as
having a MOZ_UPDATE_CHANNEL of "release", but an app.update.channel of "beta"
MozReview-Commit-ID: 3EzzDtQj8Kw
--HG--
extra : rebase_source : 371d2b804cad4fff3fc6a954621e651940867435
The canvas prompt is extremely annoying. It happens everyone, automatically. And in
99.9% (not scientific) of cases it is not triggered by user input, but my automatic
tracking scripts.
This commit will automatically decline the canvas read if it was not triggered by
user input.
Just in case this breaks something irrepairably, we have a cutoff pref.
We don't intend to keep this pref forever, and have asked anyone who sets it to
tell us why.
MozReview-Commit-ID: CxNkuraRWpV
--HG--
extra : rebase_source : 12cfc94cecbd378c0859ae50066c6338bcaa6692
image.mem.volatile.min_threshold_kb is the minimum buffer allocation for
an image frame in KB before it will use volatile memory. If it is less
than it will use the heap. This only is set to > 0 on Android.
image.mem.animated.use_heap forces image frames to use the heap if it is
for an animated image. This is only enabled for Android, and was
previously a compile time option also for Android.
"Include what you use."
--HG--
extra : rebase_source : 2239a380029e0efbc9dd3042459222a67c38d70f
extra : amend_source : 4453c32cc469caa592049167205666997f1a1e7b
extra : histedit_source : a533edd4a4d3d0642b08989e93674661d27baa6a%2C37d27eeef9580381ccc0de8507f60166dabf1730
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : f2a17aee7bb66a7ba8652817d43b9aa7ec7ef710
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : 592d13349a8c4627c7ce3146ec592f577b39f3cc
This was first suggested 17 years ago!
The error recovery works by just scanning forward for the next ';' token.
This change allows a lot of the gtest tests to be combined.
MozReview-Commit-ID: CbZ2OFtdIxf
--HG--
extra : rebase_source : 5a43fff06e88b45a095725856bbe1e6b5470c9a0
The image decoding thread pool can grow to be quite large, up to 32
threads, depending on the number of processors on the system. If the
user is not actively browsing, these threads are occupying resources
which could be reused elsewhere. After the timeout period, it will
release up to half of the threads in the pool.
The meaning of "possibly-changed" is provided by the big comment above
MustSendToContentProcesses.
On a new profile this reduces the number of prefs sent like so:
- Command-line: 222 --> 3
- IPC: 3129 --> 130
On an older profile:
- Command-line: 222 --> 3
- IPC: 3165 --> 180
MozReview-Commit-ID: DcgedhXhZd8
--HG--
extra : rebase_source : acef424fab5031347cbcbd5c3e6a24ee66895ef9
No Nightly testers don't report new compatibility issue. Additionally, if we
make Firefox use <div> as defaultParagraphSeparator in release build, web
services may stop supporting our current behavior quickly because they can
get rid of hack for us. Therefore, we should do this in the cycle of Gecko 60
which is next ESR. If we did this later, ESR users may have become not to be
able to use existing web services suddenly immediately after we did this in 61
or 62. We should avoid this bad scenario.
MozReview-Commit-ID: 7Um79Ky7n8i
--HG--
extra : rebase_source : 45c6d521ddc1166decb60cc8437ffb703b1e9aff
This has two advantages. First, it reduces memory usage, as per the following
calculation.
64-bit:
- Old sizes:
- sizeof(Pref) = 32
- New sizes:
- sizeof(PrefEntry) = 16
- sizeof(Pref) = 32
- Change:
- -16 per empty slot in the hash table
- +16 per used slot
- A win if less than half the table slots are used
32-bit
- Old sizes:
- sizeof(Pref) = 20
- New sizes:
- sizeof(PrefEntry) = 8
- sizeof(Pref) = 16
- Change:
- -12 per empty slot in the hash table
- +4 per used slot in the hash table
- A win if table is < 75% full
Table size:
- The table is currently less than half full: ~3100 used out of 8192 slots.
- The table is always <= 75% full, because that's the max load factor (for
non-gigantic tables).
- Therefore it's a win for both cases.
Old sizes, chrome process, 64-bit:
> 718,712 B (00.36%) -- preferences
> +--262,176 B (00.13%) -- hash-table
> +--197,384 B (00.10%) -- callbacks
> +--114,688 B (00.06%) -- pref-name-arena
> +---92,240 B (00.05%) -- root-branches
> +---30,456 B (00.02%) -- string-values
> +---21,688 B (00.01%) -- cache-data
> +-------80 B (00.00%) -- misc
New sizes, chrome process, 64-bit:
> 672,568 B (00.41%) -- preferences
> +--181,160 B (00.11%) -- callbacks
> +--131,104 B (00.08%) -- hash-table # smaller
> +--114,688 B (00.07%) -- pref-name-arena
> +--101,152 B (00.06%) -- pref-values # new
> +---92,240 B (00.06%) -- root-branches
> +---30,456 B (00.02%) -- string-values
> +---21,688 B (00.01%) -- cache-data
> +-------80 B (00.00%) -- misc
Old sizes, smallest content process, 64-bit:
> 500,712 B (02.89%) -- preferences
> +--262,176 B (01.51%) -- hash-table
> +--114,688 B (00.66%) -- pref-name-arena
> +---62,520 B (00.36%) -- callbacks
> +---30,456 B (00.18%) -- string-values
> +---17,832 B (00.10%) -- cache-data
> +---12,960 B (00.07%) -- root-branches
> +-------80 B (00.00%) -- misc
New sizes, smallest content process, 64-bit:
> 470,792 B (02.70%) -- preferences
> +--131,104 B (00.75%) -- hash-table # smaller
> +--114,688 B (00.66%) -- pref-name-arena
> +--101,152 B (00.58%) -- pref-values # new
> +---62,520 B (00.36%) -- callbacks
> +---30,456 B (00.17%) -- string-values
> +---17,832 B (00.10%) -- cache-data
> +---12,960 B (00.07%) -- root-branches
> +-------80 B (00.00%) -- misc
The "hash-table" values drop by more than the size of the new "pref-values"
value.
On 64-bit, this reduces memory usage per process by 30--40 KB. On 32-bit, the
number is slightly more.
The second major advantage of this change is flexibility -- it opens up the
possibility of different Pref objects being stored in different way. For
example, static Prefs could be stared statically, letting them be shared
between processes so long as they don't change (see bug 1437168).
MozReview-Commit-ID: KmgbJaoOQ1J
--HG--
extra : rebase_source : 9f8201583432c1414ab3e17e80fe23a369ac264b
This feature is confusing for Nightly users in its current state, and the
suggested websites, in foreign languages, may look worrisome to some.
Bug 1340663 must figure out these issues before re-enabling the feature.
MozReview-Commit-ID: 6RJ0Ff1B3AJ
--HG--
extra : rebase_source : 569b5ae833c4f5c05656522d0d9d0ad00679c370
This construct is nicer than NS_INTERFACE_MAP_BEGIN and assures the
reader there's no weirdness in the QI implementation. This change does
mean that PGO doesn't get an opportunity to measure the frequency of
which interfaces are QI'd most often. I think this is probably an OK
tradeoff to make, given the prevalence of NS_IMPL_QUERY_INTERFACE
elsewhere in the codebase.
The one thing we have to ensure with this change is that the ambiguous
QI to nsISupports uses the proper class after the change. The
NS_IMPL_QUERY_INTERFACE macro chooses the first interface listed to
disambiguate the cast to nsISupports.
The image decoding thread pool can grow to be quite large, up to 32
threads, depending on the number of processors on the system. If the
user is not actively browsing, these threads are occupying resources
which could be reused elsewhere. After the timeout period, it will
release up to half of the threads in the pool.
This lets us have a proper constructor for Pref, which is nice.
The patch also adds a missing case to PrefTypeToString(), and reorders the
fields in Pref to be more sensible.
MozReview-Commit-ID: A01ULF4q08O
--HG--
extra : rebase_source : 835e494ad18e3ea4de9f02beca8266551bfffe5e
mZips key is used only for internal hashtable lookups, so GetPersistentDescriptor is suitable.
MozReview-Commit-ID: 48wDOSjyo3r
--HG--
extra : rebase_source : 03c4b47812dade1d3e321727aafacfbc12bcbf32
extra : intermediate-source : 85a0b6bc25a1f960767ac28ff23a8c26829946a2
extra : source : 544bf26e258d42c835c80672416b0e29a48ba33b
They currently fail to pass on `aKind`, always getting the user value (when
possible). There are three callsites that are affected:
- nsSHistory::Startup, docshell/shistory/nsSHistory.cpp.
- FeatureState::SetDefaultFromPref(), in gfx/config/gfxFeature.cpp.
- gfxPlatform::InitOMTPConfig(), in gfx/thebes/gfxPlatform.cpp.
The patch also adds a gtest that would have failed prior to the fix.
MozReview-Commit-ID: L0U1XQmPUFc
--HG--
extra : rebase_source : d51d09836609c5a45d0b9f20570427681d8b3309
Similar to ATOK, Japanist 10 requests all or part of composition string.
If we return TS_E_NOLAYOUT in this case, you'll see candidate window at
top-left of the screen.
For avoiding this issue, we should not return TS_E_NOLAYOUT to Japanist 10
when the query range is in composition string.
MozReview-Commit-ID: 2OPafUO5PQC
--HG--
extra : rebase_source : bd7a594d8d3540374d61860651b69528aa6e3793
This patch rearranges these functions so that nsPrefBranch::GetPrefType() calls
into Preferences::GetType(), because all other nsPrefBranch methods depend on
Preferences methods.
The patch also removes the `aKind` argument from GetType(), because it has no
effect -- a pref only has one type, regardless of whether it has a default
value, a user value, or both.
MozReview-Commit-ID: J3vxFPaP8S3
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
Specifically:
- Make the warning about editing in all-caps;
- Make it clear that about:config is a browser thing;
- Add a mention of the user.js file;
- Use C++ comments, because I prefer them to C comments and I am the module
owner :)
MozReview-Commit-ID: 9GXS5nNHywO
The prefs parser has two significant problems.
- It doesn't separate tokenizing from parsing.
- It is implemented as a loop around a big switch on a "current state"
variable.
As a result, it is hard to understand and modify, slower than it could be, and
in obscure cases (involving comments and whitespace) it fails to parse what
should be valid input.
This patch replaces it with a recursive descent parser (albeit one without any
recursion!) that has separate tokenization. The new parser is easier to
understand and modify, more correct, and has better error messages. It doesn't
do error recovery, but that would be much easier to add than in the old parser.
The new parser also runs about 1.9x faster than the existing parser. (As
measured by parsing greprefs.js's contents from memory 1000 times in
succession, omitting the prefs hash table construction. If the table
construction is included, it's about 1.6x faster.)
The new parser is slightly stricter than the old parser in a few ways.
- Disconcertingly, the old parser allowed arbitrary junk between prefs
(including at the start and end of the prefs file) so long as that junk
didn't include any of the following chars: '/', '#', 'u', 's', 'p'. I.e.
lines like these:
!foo@bar&pref("prefname", true);
ticky_pref("prefname", true); // missing 's' at start
User_pref("prefname", true); // should be 'u' at start
would all be treated the same as this:
pref("prefname", true);
The new parser disallows such junk because it isn't necessary and seems like
an unintentional botch by the old parser.
- The old parser allowed character 0x1a (SUB) between tokens and treated it
like '\n'.
The new parser does not allow this character. SUB was used to indicate
end-of-file (*not* end-of-line) in some old operating systems such as MS-DOS,
but this doesn't seem necessary today.
- The old parser tolerated (with a warning) invalid escape sequences within
string literals -- such as "\q" (not a valid escape) and "\x1" and "\u12"
(both of which have insufficient hex digits) -- accepting them literally.
The new parser does not tolerate invalid escape sequences because it doesn't
seem necessary and would complicate things.
- The old parser tolerated character 0x00 (NUL) within string literals; this is
dangerous because C++ code that manipulates string values with embedded NULs
will almost certainly consider those chars as end-of-string markers.
The new parser treats NUL chars as end-of-file, to avoid this danger and
because it facilitates a significant optimization (described within the
code).
- The old parser allowed integer literals to overflow, silently wrapping them.
The new parser treats integer overflow as a parse error. This seems better,
and it caught existing overflows of places.database.lastMaintenance, in
testing/profiles/prefs_general.js (bug 1424030) and
testing/talos/talos/config.py (bug 1434813).
The first of these changes meant that a couple of existing prefs with ";;" at
the end had to be changed (done in the preceding patch).
The minor increase in strictness shouldn't be a problem for default pref files
such as greprefs.js within the application (which we can modify), nor for
app-written prefs files such as prefs.js. It could affect user-written prefs
files such as user.js; the experience above suggests that integer overflow and
";;" are the most likely problems in practice. In my opinion, the risk here is
acceptable.
The new parser also does a better job of tracking line numbers because it (a)
treats "\r\n" sequences as a single end-of-line marker, and (a) pays attention
to end-of-line sequences within string literals.
Finally, the patch adds thorough tests of both valid and invalid syntax.
MozReview-Commit-ID: JD3beOQl4AJ
The prefs parser has two significant problems.
- It doesn't separate tokenizing from parsing.
- It is implemented as a loop around a big switch on a "current state"
variable.
As a result, it is hard to understand and modify, slower than it could be, and
in obscure cases (involving comments and whitespace) it fails to parse what
should be valid input.
This patch replaces it with a recursive descent parser (albeit one without any
recursion!) that has separate tokenization. The new parser is easier to
understand and modify, more correct, and has better error messages. It doesn't
do error recovery, but that would be much easier to add than in the old parser.
The new parser also runs about 1.9x faster than the existing parser. (As
measured by parsing greprefs.js's contents from memory 1000 times in
succession, omitting the prefs hash table construction. If the table
construction is included, it's about 1.6x faster.)
The new parser is slightly stricter than the old parser in a few ways.
- Disconcertingly, the old parser allowed arbitrary junk between prefs
(including at the start and end of the prefs file) so long as that junk
didn't include any of the following chars: '/', '#', 'u', 's', 'p'. I.e.
lines like these:
!foo@bar&pref("prefname", true);
ticky_pref("prefname", true); // missing 's' at start
User_pref("prefname", true); // should be 'u' at start
would all be treated the same as this:
pref("prefname", true);
The new parser disallows such junk because it isn't necessary and seems like
an unintentional botch by the old parser.
- The old parser allowed character 0x1a (SUB) between tokens and treated it
like '\n'.
The new parser does not allow this character. SUB was used to indicate
end-of-file (*not* end-of-line) in some old operating systems such as MS-DOS,
but this doesn't seem necessary today.
- The old parser tolerated (with a warning) invalid escape sequences within
string literals -- such as "\q" (not a valid escape) and "\x1" and "\u12"
(both of which have insufficient hex digits) -- accepting them literally.
The new parser does not tolerate invalid escape sequences because it doesn't
seem necessary and would complicate things.
- The old parser tolerated character 0x00 (NUL) within string literals; this is
dangerous because C++ code that manipulates string values with embedded NULs
will almost certainly consider those chars as end-of-string markers.
The new parser treats NUL chars as end-of-file, to avoid this danger and
because it facilitates a significant optimization (described within the
code).
- The old parser allowed integer literals to overflow, silently wrapping them.
The new parser treats integer overflow as a parse error. This seems better,
and it caught an existing overflow in testing/profiles/prefs_general.js, for
places.database.lastMaintenance (see bug 1424030).
The first of these changes meant that a couple of existing prefs with ";;" at
the end had to be changed (done in the preceding patch).
The minor increase in strictness shouldn't be a problem for default pref files
such as greprefs.js within the application (which we can modify), nor for
app-written prefs files such as prefs.js. It could affect user-written prefs
files such as user.js; the experience above suggests that ";;" is the most
likely problem in practice. In my opinion, the risk here is acceptable.
The new parser also does a better job of tracking line numbers because it (a)
treats "\r\n" sequences as a single end-of-line marker, and (a) pays attention
to end-of-line sequences within string literals.
Finally, the patch adds thorough tests of both valid and invalid syntax.
MozReview-Commit-ID: 8EYWH7KxGG
* * *
[mq]: win-fix
MozReview-Commit-ID: 91Bxjfghqfw
--HG--
extra : rebase_source : a8773413e5d68c33e4329df6819b6e1f82c22b85
This reverts the change introduced in bug 1394053.
Google has made the download protection lists available to everyone
and so we no longer need to restrict the download protection feature
to official builds.
MozReview-Commit-ID: CQcG5Ip1mDV
--HG--
extra : rebase_source : 55ff4f1e5a09e3c83ad9b24b2eb44789834b2357
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
UI Events declares that keypress event should be fired when the keypress event
causes some text input. However, we're keeping our traditional behavior for
historical reasons because our internal event handlers (including event
handlers of Thunderbird) handles keypress events for any keys. Therefore,
for minimizing the side effect, we should stop kicking keypress event handlers
in the default event group in web content.
This patch adds new pref for enabling the standard behavior in web content.
Additionally, creates WidgetKeyboardEvent::IsInputtingText() for sharing the
check logic between TextEventDispatcher and TextEditor/HTMLEditor.
MozReview-Commit-ID: 3rtXdLBPeVC
--HG--
extra : rebase_source : 2fc3c9a09840d0d03800c9a42bb83ca76a8db2d5
* Makes the implementation of nsStandardURL::Mutator into a template called TemplatedMutator<T>
* Makes both nsStandardURL::Mutator and SubstitutingURL::Mutator extend TemplatedMutator<T>
MozReview-Commit-ID: EpxFpBkrdSK
--HG--
extra : rebase_source : 07d568ff84fb199c7549ae5f402e01e4b86c1c37
On the off chance exposing navigator.webdriver turns out
to be catastrophic, this patch introduces a new preference
dom.webdriver.enabled that controls its exposure. This lets us
flip a pref on release without releasing an update.
MozReview-Commit-ID: KisaqPb0Y4V
--HG--
extra : rebase_source : 4000a1d283e70eda988262efc70de801eec3586a
Provides an optional resolver mechanism for Firefox that allows running
together with or instead of the native resolver.
TRR offers resolving of host names using a dedicated DNS-over-HTTPS server
(HTTPS is required, HTTP/2 is preferable).
DNS-over-HTTPS (DOH) allows DNS resolves with enhanced privacy, secure
transfers and improved performance.
To keep the failure rate at a minimum, the TRR system manages a dynamic
persistent blacklist for host names that can't be resolved with DOH but works
with the native resolver. Blacklisted entries will not be retried over DOH for
a couple of days. "localhost" and names in the ".local" TLD will not be
resolved via DOH.
TRR is preffed OFF by default and you need to set a URI for an available DOH
server to be able to use it. Since the URI for DOH is set with a name itself,
it may have to use the native resolver for bootstrapping. (Optionally, the
user can set the IP address of the DOH server in a pref to avoid the required
initial native resolve.)
When TRR starts up, it will first verify that it works by checking a
"confirmation" domain name. This confirmation domain is a pref by default set
to "example.com". TRR will also by default await the captive-portal detection
to raise its green flag before getting activated.
All prefs for TRR are under the "network.trr" hierarchy.
The DNS-over-HTTPS spec: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-03
MozReview-Commit-ID: GuuU6vjTjlm
--HG--
extra : rebase_source : 53fcca757334090ac05fec540ef29d109d5ceed3
Adds new network.http.referer.defaultPolicy.pbmode pref which defaults to 2.
When setting referrer from default policy, checks mLoadInfo OriginAttributes
for mPrivateBrowsingId > 0 to detect PBM.
MozReview-Commit-ID: 7SfNk0dO1rW
--HG--
extra : rebase_source : a050a61cad005740edde99f846a69c6a7568dbc6
- WebVR will continue to be enabled on macOS for Nightly
and Dev Edition
MozReview-Commit-ID: LpEX13yZVbb
--HG--
extra : rebase_source : 07b93a9f0cbb57fb00f17404f0cf4a37f78f6a5c
This pref does not override privacy.resistFingerprinting, but when it is set (and
privacy.resistFingerprinting is not) we will still adjust the precision of almost
all timers. The adjustment amount is the second pref, which is defaulted to
20us but now dynamically adjustable (in the scale of microseconds.)
This patch does _not_ address the performance API, which privacy.resistFingerprinting
disables.
We are landing this preffed on at the current value we clamp performance.now() at
which is 20us.
MozReview-Commit-ID: ESZlSvH9w1D
--HG--
extra : rebase_source : a8afead1bdba958c6c7b383b2216dacb3a1b135c
This is a follow-up to bug 1409249. There are a lot of places where our
factory singleton constructors either don't correctly handle their returned
references being released by the component manager, or do handle it, but in
ways that are not obvious.
This patch handles a few places where we can sometimes wind up with dangling
singleton pointers, adds some explanatory comments and sanity check
assertions, and replaces some uses of manual refcounting with StaticRefPtr and
ClearOnShutdown.
There are still some places where we may wind up with odd behavior if the
first QI for a getService call fails. In those cases, we wind up destroying
the first instance of a service that we create, and re-creating a new one
later.
MozReview-Commit-ID: ANYndvd7aZx
--HG--
extra : rebase_source : acfb0611a028fef6b9387eb5d1d9e285782fbc7c
This commit adds a paint worker thread pool to PaintThread, and dispatches
tiled paints to it. The thread pool is only created if tiling is enabled,
and its size is set by 'layers.omtp.paint-workers' and defaults to 1. If
-1 is specified, it will be sized to 'max((cpu_cores * 3) / 4, 1)'.
The one tricky part of dispatching tiled paints to a thread pool is the
AsyncEndLayerTransaction message that must execute once all paints are
finished. Previously, this runnable would be queued after all the paints
had been queued, ensuring it would be run after they had all completed.
With a thread pool, there is no guarantee. Instead this commit, uses
a flag on CompositorBridgeChild to signify whether all of the paints
have been queued ('mOutstandingAsyncEndLayerTransaction'), and after
every tiled paint it is examined to see if that paint was the last
paint, and if it is to run AsyncEndLayerTransaction. In addition,
if the async paints complete before we even mark the end of the
layer transaction, we queue it like normal.
The profiler markers are also complicated by using a thread pool.
I don't know of a great way to keep them working as they are per
thread, so for now I've removed them. I may have been the only
one using them anyway.
MozReview-Commit-ID: 5LIJ9GWSfCn
--HG--
extra : rebase_source : 0c26806f337a1b4b1511945f9c72e787b426c5ba
Most of the Shadow DOM related code are behind "dom.webcomponents.enabled" and
this pref is only used by Shadow DOM right now, so we should rename it to
"dom.webcomponents.shadowdom.enabled"
MozReview-Commit-ID: er1c7AsSSW
Andreea Pavel
Honza Bambas
Tom Ritter
Csoregi Natalia
Robert Longson
Noemi Erli
Liang-Heng Chen
Sebastian Hengst
Valentin Gosu
Johann Hofmann
Brian Birtles
Jonathan Kingston
shindli
Kris Maglione
Daniel Holbert
Masayuki Nakano
arthur.iakab
Kearwood Gilbert
Dorel Luca
Tarek Ziadé
Emilio Cobos Álvarez
Ted Mielczarek
Kartikaya Gupta
Andrew Osmond
Narcis Beleuzu
Andrew Swan
Nicholas Nethercote
Jan de Mooij
Bogdan Tara
Jan Beich
Jan Odvarko
Nicolas B. Pierron
Daniel Stenberg
Jeff Walden
Margareta Eliza Balazs
Catalin Badea
Bob Owen
Florian Quèze
Nathan Froyd
Chris H-C
Kit Cambridge
Eric Rahm
Jonathan Kew
Makoto Kato
Matt Woodrow
Jason Orendorff
Gurzau Raul
Andreas Pehrson
Xidorn Quan
Tooru Fujisawa
Marco Bonardo
Jon Coppeard
Ciure Andrei
Ryan Hunt
Masatoshi Kimura
Tom Schuster
Andrew McCreight
Alexis Beingessner
Andrea Marchesini
Eugen Sawin
Adrian Wielgosik
Cameron McCormack
Cosmin Sabou
Francois Marier
Matthew Gregan
Brindusan Cristian
vinoth
cku
Jeremy Chen
Coroiu Cristina
Andreas Tolfsen
Dragana Damjanovic dd.mozilla@gmail.com
Jared Wein
Kyle Machulis
Sylvestre Ledru
Mark Striemer
Ryan VanderMeulen
Luke Crouch
Nico Grunbaum
Shane Caraveo
Andreas Farre
Paolo Amadini
Kate McKinley
Kearwood "Kip" Gilbert
Milan Sreckovic
Botond Ballo
Jessica Jong
Edgar Chen
KuoE0