They both have two callsites, but in one of those they appear together, where
much of the code can be replaced with a ClearAndPrepareForLength() call.
MozReview-Commit-ID: 1A771gsHWan
--HG--
extra : rebase_source : c6f26b9a825155c7b7c885540cf9f34f8b8eace7
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.
--HG--
extra : rebase_source : b885ee784704819e181430200af5ef762e269d14
Bug 1108587 seems to suggest that the grace period for nsTerminator is
too short for ASAN builds, which take much longer to shutdown. This
patch changes the grace period from 1 minute to 3 minutes, hoping that
this will be sufficient. Somewhere along the way, we also extend the
duration of AsyncShutdown, because that's the simplest way to do both
at once.
MozReview-Commit-ID: 28eWO5m6Wh3
--HG--
extra : rebase_source : eae9db952d5395f986781f3cbd23507b715fa8c9
The various getters and setters are in a confusing order. This patch puts them
in a more sensible order. It also streamlines the comments, which were
generally low-value and in some cases incorrect.
MozReview-Commit-ID: 3ngzZDSt0JI
--HG--
extra : rebase_source : 8a5a66f65621889483d2df9f4487194172f70804
widget.allow-client-side-decoration is no longer used, titlebar rendering is controled by browser.tabs.drawInTitlebar only.
MozReview-Commit-ID: LHdBio4Gfry
--HG--
extra : rebase_source : 7cdd788978d0209702d5212ac7be4daa1c616393
AutoplayPolicy is used to manage autoplay logic for all kinds of media,
including MediaElement, Web Audio and Web Speech.
MozReview-Commit-ID: R1TxMkarIw
--HG--
extra : rebase_source : 8c608a1d12c8e205391a91f22e1532bc4f2c8f16
This class isn't being used right now, and MozURL is a much better alternative if interaction with rust URLs is required.
MozReview-Commit-ID: ADdYRrrTnr6
--HG--
extra : rebase_source : b36aa26c20e7daaadab1f3360bab0ed4681eb7f8
There's no good reason why these can't be code constants.
Especially given that, due to a bug, changes to the
"idle_queue.{min,long}_period" constants were not being passed onto the C++
code!
Here's why: those two prefs were specified as integers in all.js. But we used
AddFloatVarCache() to set up the reading of those prefs. libpref fakes floats
by storing them as strings and then converting them to floats when they are
read.
Which means that AddFloatVarCache() used to fail to get the value from all.js
-- because there's a type mismatch, int vs. string -- and instead use the
fallback default. That value is the same as the one in all.js, which is lucky.
But if someone changed the value in about:config to 100 (an integer), a similar
failure would have occured and the value used by the C++ code wouldn't be
updated!
Also note that idle_queue.max_timer_thread_bound did not have a value in
all.js.
What a mess!
--HG--
extra : rebase_source : 86f8fa905163803eb95007609c029e18c2c4f586
There's no good reason why these should't just be constants. The patch also
appends "MiB" to some of the C++ values to make their meaning clearer.
This patch fixes one outright bug, and one inconsistency.
The bug is due to a prefname mismatch:
- ContentPrefs.cpp and AvailableMemoryTracker.cpp use
"memory.low_virtual_mem_threshold_mb".
- all.js uses "memory.low_virtual_memory_threshold_mb".
Which means that "memory.low_virtual_memory_threshold_mb" showed up in
about:config, but if you changed it nothing would happen because the callback
listened for changes to to "memory.low_virtual_mem_threshold_mb"!
Now for the inconsistency. The above means we actually use a value of 256 for
the virtual memory threshold, even though all.js says 128. But we *do* use a
value of 128 for the commit space threshold, because that's what all.js says
and that prefname is used correctly everywhere. The patch changes the commit
space threshold to 256 for consistency with the virtual memory threshold.
What a mess!
--HG--
extra : rebase_source : d3842c732efa9ab0e90eeb6a4f341aeb289589ed
This was originally added for b2g, where the pref had a different value.
Bug 1398033 enabled it everywhere.
--HG--
extra : rebase_source : c8bb03190cd00d25e6c2ec62a99ed8e911e08197
libpref has callbacks. You can register a callback function against a
particular pref (or pref prefix), and it'll be called when any matching pref
changes.
This is implemented in two layers. The lower layer is the list of CallbackNode
objects, pointed to by gFirstCallback.
The upper layer involves gObserverTable, which is a hash table of ValueObserver
objects. It is used for callbacks registered via
Preferences::RegisterCallback() and Preferences::Add*VarCache(), but not for
observers registered with Preferences::Add{Weak,Strong}Observer(). If multiple
callbacks with identical prefnames, callback functions and MatchKinds occur,
they are commoned up into a single ValueObserver, which is then wrapped by a
single CallbackNode. (The callbacks within a single ValueObserver can have
different void* aClosure args; ValueObserver keeps those in an nsTArray.)
Note also that gObserverTable is very inelegant, with duplication of data
between the keys and the values due it being a
nsRefPtrHashtable<ValueObserverHashKey, ValueObserver> and ValueObserver being
a subclass of ValueObserverHashKey(!)
This extra layer might make sense if there were a lot of commoning up
happening, but there's not. Across all process kinds there is an average of
between 1.2 and 1.7 closures per ValueObserver. The vast majority have 1
closure, and there are a handful that have multiple; the highest number I've
seen is 71.
(Note that this two-layer design probably seemed more natural back when libpref
was spread across multiple files.)
This patch removes the ValueObserver layer. The only tricky part is that there
is a notion of a MatchKind -- ExactMatch or PrefixMatch -- which exists in the
ValueObserverLayer but not in the CallbackNode layer. So the patch moves the
MatchKind into the CallbackNode layer, which is straightforward.
On Linux64 this reduces memory usage by about 40 KiB in the parent process and
about 30 KiB in each content processes.
The performance implications are minor.
- The list of CallbackNodes is a bit longer, so when a pref is changed we must
check more nodes. But we avoid possibly doing prefname matching twice.
- Callback registration is much faster, just a simple list prepend, without any
hash table insertion required.
- Callback unregistration is probably not much different. There is a longer
list to traverse, but no hash table removal.
- Pref lookup is by far the hottest libpref operation, and it's unchanged.
For perf to be genuinely affected would require (a) a *lot* more
almost-duplicate callbacks that would have been commoned up, and (b) frequent
changing of the pref those callbacks are observing. This seems highly unlikely.
MozReview-Commit-ID: 6xo4xmytOf3
--HG--
extra : rebase_source : cf9884a8a40b2cc3b00ab165ae5ab4ec3383f72d
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.
--HG--
extra : rebase_source : fb7af066adfa0491a79fae6282a62b08661553c8
Pref callbacks registered via Preferences::Add*VarCache() are wrapped in a
ValueObserver -- which groups all callback requests that have the same prefname
and callback function -- and the ValueObserver is put into gObserverTable. This
is reasonable.
Observers registered via nsPrefBranch::Add{Weak,Strong}Observer() are wrapped
in a PrefCallback, and the PrefCallback is put into sRootBranch->mObservers.
This is also reasonable.
Pref callbacks registered via Preferences::RegisterCallback() are conceptually
similar to those registered via Preferences::Add*VarCache(). However, they are
implemented by using *both* of the above mechanisms: they are wrapped in a
ValueObserver which is put into gObserverTable, *and* that ValueObserver is then
wrapped in a PrefCallback which is put into sRootBranch->mObservers.
Using both mechanisms isn't necessary, so this patch removes the
PrefCallback/mObservers part. This makes Preferences::RegisterCallback() work
in much the same way as Preferences::Add*VarCache().
Specifically:
- Preferences::RegisterCallback() now calls PREF_RegisterCallback() instead of
Preferences::AddStrongObserver(). This makes it more similar to
RegisterPriorityCallback().
- Preferences::UnregisterCallback() now explicitly calls
PREF_UnregisterCallback() instead of Preferences::RemoveObserver (which
previously happened via ~ValueObserver() when the ValueObserver was removed
from gObserverTable and its refcount dropped to zerod).
MozReview-Commit-ID: 1tEQNeYrBUU
--HG--
extra : rebase_source : 431a42402397a172d562b81b8d46418503bb8dfe
The notable part of this change is Shutdown(). I've made it just null out
sPreferences, contrary to the old comment, which was strange for a couple of
reasons:
- ~Preferences() used to null out sPreference, which is backwards compared to
how this sort of thing normally works.
- In both the before and after cases, as far as I can tell,
Preferences::Shutdown() is called but ~Preferences() is never called;
something keeps the singleton Preferences instance alive until process
termination.
MozReview-Commit-ID: Ab0ui31rVcI
sRootBranch and sDefaultRootBranch have the same lifetime as sPreferences, so
this patch makes them non-static nsCOMPtr<> members of Preferences.
MozReview-Commit-ID: 1TLhh13ZpBI
--HG--
extra : rebase_source : 9419cd205b9a06f7ae82722a6732e3fc2722473b
It's no longer needed, now that legacy extensions aren't supported.
Pieces removed include the following.
- The "load-extension-default" observer notification.
- The code for reading defaults/preferences/*.js from extensions.
- The unit test for this stuff.
- A crash reporter annotation relating to very long prefs set by add-ons.
- All references to "ExtPrefDL".
MozReview-Commit-ID: KMBoYn3uZ3x
--HG--
extra : rebase_source : 4dc8ffd425c6cdf06806409090c4f9d04a64930b
Behaviour is controlled through the media.navigator.video.vp9_preferred preference.
MozReview-Commit-ID: J06ArFYNmTk
--HG--
extra : rebase_source : a25bd4783fde0acf8291ee440745a619d3fa7db8
This patch does the following.
- Reduces nesting and simplifies control flow by handling failure cases
earlier, and makes all three functions have identical structure.
- Avoids unnecessary temporary local variables, including |rv|.
- Removes low-value comments, including some misleading ones (e.g. "This
function will perform conversion...").
- PREF_GetCStringValue() previously did not check HasDefaultValue(), unlike the
other two. It now does.
- PREF_GetCStringValue() now calls SetIsVoid(true) at the start, so that
aValueOut will be Voided on all failure paths.
MozReview-Commit-ID: 2uCSv76Y8eu
--HG--
extra : rebase_source : 9ca9148ad0a5069bdd3e08aec0038216d27ea092
This patch converts it to use Gecko strings instead of C strings, which makes
it much nicer.
MozReview-Commit-ID: KtRp3vaXwN5
--HG--
extra : rebase_source : c6788cbed5c4b932eb5b4119c407aea538cb1799
This was created for B2G and isn't really useful otherwise. It only works on
Linux, and it's behind the memory.system_memory_reporter pref, which is false
by default.
The patch also removes LinuxUtils.{h,cpp}, which is no longer used.
--HG--
extra : rebase_source : b97a018be11a79f83855a73b88020bfa86e60f78
This is needed for local developer builds to enable extended
telemetry recording by default. As a consequence, other subsystems
relying on this prefs will turn on (e.g. experiments, BHR, ...).
MozReview-Commit-ID: W3RarufCdY
--HG--
extra : rebase_source : 8690e969baad1b9191ea3fef9fb7dd6e41e00de7
In Unified Telemetry toolkit.telemetry.enabled controls whether we send base
collection data or extended collection. The difference is mostly in volume, not
in kind (though extended collection has a little stricter testing and monitoring
requirements).
Since the Preferences UI change in Firefox 56, users no longer have the ability
to change toolkit.telemetry.enabled. This is a good thing as for pre-release
users very few disabled extended collection, and even fewer release users
enabled it. This provides uniform collection based on channel which should
eventually net us some efficiencies.
Until then we need to align our use of the toolkit.telemetry.enabled pref with
the UI change that has already shipped. This is accomplished by locking t.t.e
to 'true' on pre-release channels and locking it to 'false' on everything else.
This doesn't apply to Android as it doesn't (yet) use Unified Telemetry. t.t.e
means something rather different there.
MozReview-Commit-ID: EOpWm8b0jWA
This makes the code nicer. In particular, it removes many getter_Copies()
calls. The patch also converts a lot of nsCStrings to nsAutoCString, which will
avoid heap allocation in the common case.
The patch also renames PREF_CopyCharPref() as PREF_GetCStringPref(), because
it's actually getting a string, not a char, and that matches the existing
GetCString() and GetDefaultCString() methods. Correspondingly, it also renames
PREF_SetCharPref() as PREF_SetCStringPref().
The |aPrefName| arguments in nsIPrefBranch.idl remain as |string| because they
almost always involve passing in C string literals, and passing "foo" is much
nicer than passing NS_LITERAL_CSTRING("foo").
It's worth noting that early versions of this patch used |AUTF8String| instead
of |ACString|. But it turns out that libpref stores prefs internally as Latin1.
And |ACString| is compatible with Latin1 but |AUTF8String| isn't, because
non-ASCII Latin1 strings are not valid UTF-8!
MozReview-Commit-ID: D3f7a1Vl1oE
--HG--
extra : rebase_source : e6e4b15d6d210cfd93686f96400281f02bd1d06b
In Unified Telemetry toolkit.telemetry.enabled controls whether we send base
collection data or extended collection. The difference is mostly in volume, not
in kind (though extended collection has a little stricter testing and monitoring
requirements).
Since the Preferences UI change in Firefox 56, users no longer have the ability
to change toolkit.telemetry.enabled. This is a good thing as for pre-release
users very few disabled extended collection, and even fewer release users
enabled it. This provides uniform collection based on channel which should
eventually net us some efficiencies.
Until then we need to align our use of the toolkit.telemetry.enabled pref with
the UI change that has already shipped. This is accomplished by locking t.t.e
to 'true' on pre-release channels and locking it to 'false' on everything else.
This doesn't apply to Android as it doesn't (yet) use Unified Telemetry. t.t.e
means something rather different there.
MozReview-Commit-ID: EOpWm8b0jWA
Because nsCString is nicer than UniqueFreePtr<char>.
The patch also streamlines pref_savePrefs(). And also changes StrEscape() to
always put quotations around the result, because that's needed in both call
sites.
MozReview-Commit-ID: HT7HZz4QiSN
--HG--
extra : rebase_source : 442bb6002e004803a9ecb637239a000f11ec5774
First, the patch removes the return values from PrefTypeFlags::Set*(). They
allow chained calls, but they're barely used and they just make the code harder
to read.
Second, the patch changes pref_SetValue() to not modify and return the pref
flags. It's clearer if the flags changing is done separately. This requires
passing pref_SetValue() the old type instead of the flags.
MozReview-Commit-ID: HZVS2TIlBIY
--HG--
extra : rebase_source : 6638244214cda15ceae5a1930659aed434d8261b
This makes it clear that the stored string values are never modified.
It requires some const_casts to free the strings, but that feels like an ok
trade-off.
MozReview-Commit-ID: JikBT3uwpfq
--HG--
extra : rebase_source : 1720969ba2c1ae245dff91a6d3a85d48fb669ced
There's not much use using |protected| in a |final| class.
MozReview-Commit-ID: IECyfNGZsL5
--HG--
extra : rebase_source : e734b360c18e5e040bea186d5aedf91137711861
It's always gHashTable, and all the other functions in this file work directly
on gHashTable rather than taking a parameter.
MozReview-Commit-ID: BDCEvcMlo8P
--HG--
extra : rebase_source : 8f136c100f2a4f7b2b34cfa884b8cc91c2d80e3a
At present, the "layout.css.stylo-blocklist.blocked_domains" pref is empty. It
is probably meaningless to set "layout.css.stylo-blocklist.enabled" pref to true
by default. We can set "layout.css.stylo-blocklist.enabled" pref to true by the
styloblocklist system add-on once the "layout.css.stylo-blocklist.blocked_domains"
pref is non-empty.
MozReview-Commit-ID: 2B5JnGEafLo
--HG--
extra : rebase_source : 7b694a2cbe70d2d09c1a5c2c2e4c6eec31f39a1e
It's unnecessarily general, because we only ever use
Preferences::DirtyCallback() as the callback.
And because it's no longer a callback, the patch renames DirtyCallback() as
HandleDirty().
MozReview-Commit-ID: Hl50dcxfVQq
--HG--
extra : rebase_source : 5807d2ed650466f85cd7325f2adccdc177ccb4d2
It's simple enough that having a separate function isn't helpful.
MozReview-Commit-ID: Ke9BIfp9yHU
--HG--
extra : rebase_source : 57aee451b8fd3450da4a604cefbf9fafda894b1c
Preferences.cpp has two functions named pref_DoCallback(). One of them has a
single use in the parser. This patch inlines that single use to remove the name
duplication.
MozReview-Commit-ID: HnyteQ0N5M1
--HG--
extra : rebase_source : 37a34f3fbe866eee71a7bf0bba07d9d67cc8c81d
Right now, NS_GENERIC_FACTORY_SINGLETON_CONSTRUCTOR expects singleton
constructors to return already-addrefed raw pointers, and while it accepts
constructors that return already_AddRefed, most existing don't do so.
Meanwhile, the convention elsewhere is that a raw pointer return value is
owned by the callee, and that the caller needs to addref it if it wants to
keep its own reference to it.
The difference in convention makes it easy to leak (I've definitely caused
more than one shutdown leak this way), so it would be better if we required
the singleton getters to return an explicit already_AddRefed, which would
behave the same for all callers.
This also cleans up several singleton constructors that left a dangling
pointer to their singletons when their initialization methods failed, when
they released their references without clearing their global raw pointers.
MozReview-Commit-ID: 9peyG4pRYcr
--HG--
extra : rebase_source : 2f5bd89c17cb554541be38444672a827c1392f3f
This makes it clear that the stored string values are never modified.
It requires some const_casts to free the strings, but that feels like an ok
trade-off.
MozReview-Commit-ID: JikBT3uwpfq
--HG--
extra : rebase_source : e611e57de4f059275ae2908f7300065cf953461d
Because nsCString is nicer than UniqueFreePtr<char>.
The patch also streamlines pref_savePrefs(). And also changes StrEscape() to
always put quotations around the result, because that's needed in both call
sites.
MozReview-Commit-ID: HT7HZz4QiSN
--HG--
extra : rebase_source : f8d26a8c9f7ea911272113efc56744df639c5ccf
There's not much use using |protected| in a |final| class.
MozReview-Commit-ID: IECyfNGZsL5
--HG--
extra : rebase_source : bc9597ee45583e809f89f7e558cc325460390f98
It's always gHashTable, and all the other functions in this file work directly
on gHashTable rather than taking a parameter.
MozReview-Commit-ID: BDCEvcMlo8P
--HG--
extra : rebase_source : e5d10e42401136a9a82d665d9717cf71ecf7e4ae
First, the patch removes the return values from PrefTypeFlags::Set*(). They
allow chained calls, but they're barely used and they just make the code harder
to read.
Second, the patch changes pref_SetValue() to not modify and return the pref
flags. It's clearer if the flags changing is done separately. This requires
passing pref_SetValue() the old type instead of the flags.
MozReview-Commit-ID: HZVS2TIlBIY
--HG--
extra : rebase_source : 32950f00975f7d9df63fa0af1c36e82b58516245
It's unnecessarily general, because we only ever use
Preferences::DirtyCallback() as the callback.
And because it's no longer a callback, the patch renames DirtyCallback() as
HandleDirty().
MozReview-Commit-ID: Hl50dcxfVQq
--HG--
extra : rebase_source : f453d31215de3fdb0c5b6176becf2669e7ad55f1
It's simple enough that having a separate function isn't helpful.
MozReview-Commit-ID: Ke9BIfp9yHU
--HG--
extra : rebase_source : de1518544ddb28185635628c33d356ab07480c1c
Preferences.cpp has two functions named pref_DoCallback(). One of them has a
single use in the parser. This patch inlines that single use to remove the name
duplication.
MozReview-Commit-ID: HnyteQ0N5M1
--HG--
extra : rebase_source : 93f963d3ba445c1c3a482fa95dbab33e57dae188
Some odd touchpad utils give focus to window under mouse cursor when user tries
to scroll the content with swiping or something.
This is really odd behavior because some windows like popup windows doesn't
want focus. However, such ones do actually. For making easier to check such
device's behavior, we should have a pref to emulate such behavior.
MozReview-Commit-ID: 6euwpHn7blf
--HG--
extra : rebase_source : cc23f08f422f25f2851404696e06e069c7936186
"Nonsecure HTTP" here just means regular, not-HTTPS HTTP. It doesn't mean HTTPS without the `Secure` cookie flag. Honor the expiration time of third-party cookies set over HTTPS, whether or not they have the `Secure` cookie flag. If a third-party cookie is set over HTTPS and then later sent in nonsecure HTTP request (which is allowed for cookies without the `Secure` cookie flag), the cookie won't be turned into a session cookie unless the nonsecure HTTP response sets a new cookie value.
This feature is controlled by the pref "network.cookie.thirdparty.nonsecureSessionOnly".
MozReview-Commit-ID: HlCg21JyvNC
--HG--
rename : extensions/cookie/test/unit/test_cookies_thirdparty_session.js => extensions/cookie/test/unit/test_cookies_thirdparty_nonsecure_session.js
extra : source : d1be2e4265201efd3ee93e965ac68561f548fd05
extra : intermediate-source : f5b382fa1b70e30a907b1f10d74f8c0c6dff344e
nsIPrefLocalizedString is meant to be a wrapper for nsISupportsString,
basically identical but with a different identifier. But it's not a
sub-interface of nsISupportsString. Instead it (almost) duplicates
nsISupportsString's internals.
Specifically, nsISupportsString has `attribute AString data`, resulting in
these C++ methods:
> NS_IMETHOD GetData(nsAString& aData)
> NS_IMETHOD SetData(const nsAString& aData)
nsIPrefLocalizedString has `attribute wstring data`, resulting in these C++
methods:
> NS_IMETHOD GetData(char16_t** aData)
> NS_IMETHOD SetData(const char16_t* aData)
Then we have nsPrefLocalizedString, the concrete subclass of
nsIPrefLocalizedString. It implements the AString methods via
NS_FORWARD_NSISUPPORTSSTRING, which forwards to mUnicodeString. It also
implements the wstring methods explicitly, and they just call the AString
methods. It's all a bit of a mess.
(Both interfaces also have `wstring toString()`. The forwarding works more
smoothly for that method.)
This patch changes nsIPrefLocalizedString so it is a trivial sub-interface of
nsISupportsString. This change eliminates the need for the wstring methods, so
the patch removes them as well. The net result is we have less code, and fewer
conversions between C strings and Gecko strings. The patch also merges the
nsISupportsString and nsIPrefLocalizedString cases in
nsPrefBranch::SetComplexValue(), because they are now identical. (The
nsISupportsString and nsIPrefLocalizedString cases in
nsPrefBranch::GetComplexValue() remain distinct; indeed, that's the whole
reason for having them as separate interfaces.)
This lets us replace moz_xstrdup() of string literals with AssignLiteral(),
among other improvements.
--HG--
extra : rebase_source : 9994d8ccb4f196cf63564b0dac2ae6c4370defb4
The layout.css.stylo-blocklist.blocked_domains pref is set to "arewestyloyet.rs"
on Nightly, but empty string on Beta. Since we're going to QA the styloblocklist
add-on in Bug 1407911, we make the prefs aligned in both Beta and Nightly in this
patch.
MozReview-Commit-ID: HoleJvVYm7o
--HG--
extra : rebase_source : cb8104f3d7fdb99fe0ea6ee84781c4b421a8f421
This patch declares a new default action, "horizontal scroll", this scrolls
content horizontally with deltaY of wheel events and ignores deltaX and deltaZ.
This is used for default action with Shift key in default setting except on
macOS. On macOS, legacy mouse's vertical wheel operation with Shift key causes
native horizontal wheel event. Therefore, we don't need to use this new
default action on macOS. Additionally, old default action with Shift key,
navigating history, is moved to with Alt key. This makes same settings between
macOS and the others. So, this is better for users who use macOS and another
OS and web app developers who check wheel events only on macOS or other
platform(s).
For simpler implementation, default action handlers moves deltaY values to
deltaX values temporarily *only* while they handle wheel events. This is
performed by AutoWheelDeltaAdjuster and restored after handling it
automatically.
So, in other words, even if default action is "horizontal scroll", web apps
receives wheel events whose deltaY is not zero but its content will be
scrolled horizontally. This is same as Chromium, so, this behavior shouldn't
cause any incompatible behavior with it.
MozReview-Commit-ID: E4X3yZzLEAl
--HG--
extra : rebase_source : e20d854c6b0a181ad4c9e7304bd9ad14256481ff
After data delivery for a request has been retargeted, there's no reliable way
to get the appropriate event target to re-dispatch data events after
asynchronous processing.
While it's technically possible to retrieve the current thread from
OnDataAvailable callbacks and re-use that for later dispatch, that approach
has some issues:
1) It's not currently possible to reliably map the current thread to the
thread pool that owns it. That means that if data delivery is being targetted
to a thread pool, attempts to redispatch events to the previous delivery
thread might lead to long delays when one thread in a pool is blocked.
2) If a filter wishes to dispatch data events to the wrapped listeners before
it's recieved any data (as extensions StreamFilters sometimes do), there's no
way to determine the proper event target without waiting for initial data to
be received.
Simply returning the correct event target from the request solves both of
these problems.
MozReview-Commit-ID: CJxq7O4399R
--HG--
extra : rebase_source : db2f659ecad16daafdbcc108d7b1a51ea1af31f9
This pref is only for webrender layers mode. So we should remove it.
MozReview-Commit-ID: AxPLnc0uO1U
--HG--
extra : rebase_source : daecac41200be2244b0c6dccb66e0d61d7634691
This is possible now that all of libpref is in a single .cpp file.
For some functions, this required moving the comment from the forward
declaration to the definition.
MozReview-Commit-ID: 7XjHENZkc61
--HG--
extra : rebase_source : adc61d0463769c311915139f6e98c2f3187a2d21
Thanks to xidorn's donation, now we can do some real domain testings for stylo
blocklist mechanism. Note that we only add arewestyloyet.rs domain in Nightly
channel for testing, and the domain should be removed in other channels.
MozReview-Commit-ID: Io351w6sg5b
--HG--
extra : rebase_source : 339fdcf754c41f79ef03324697695b8e44a5d261
It's declared in Preferences.h, which Preferences.cpp includes.
MozReview-Commit-ID: 7bjcgsrbfGl
--HG--
extra : rebase_source : ea932402b7eaae876fcba2c0cfdfad2bc728cb8d
We can just use XRE_IsContentProcess() instead, because the pointer return
value is only ever used in a bool context.
MozReview-Commit-ID: 6R4Bwf1cnKU
--HG--
extra : rebase_source : 392e01cfc145f05783c4bdc7aa08486ef07982be
This is detritus from old changes that can be cleaned up now.
The patch removes the declaration of PrefChangedFunc from Preferences.cpp
because it's also in Preferences.h, which is included by Preferences.cpp.
The patch also removes the part of the comment about passing a non-zero result
because it's clearly false -- the callback has no return value.
MozReview-Commit-ID: 72cdauYsRUt
--HG--
extra : rebase_source : 84cbbcea3b0ce3242c629e428be1e81be9cb5792
Their last use was removed in bug 200524, 14.5 years ago.
MozReview-Commit-ID: FoM8KpJNA7m
--HG--
extra : rebase_source : 0c0ffb90a5e8d23cead729b71563ad2249102c96
It's unclear how to compile it; it isn't a proper test, because it just prints
stuff out without explicitly checking anything; and I bet nobody has run it in
a long time.
MozReview-Commit-ID: 48s7pCy7HC6
--HG--
extra : rebase_source : 39d3ba85bd9e45e68b7c7c4cd27b5d7a5a9272b0
Try looks good. Let's turn it on for more tests on Nightly.
MozReview-Commit-ID: 21mQfRmOYag
--HG--
extra : rebase_source : 8f51bd517816deba68dad511a9f859ab1df25baf
extra : intermediate-source : 5150eb8b0826be6578b2d8c68d6d864cc9f55f25
extra : source : 63542cbae67928b936f0472b8dca1f7035759115
This is a mixture of clang-format and manual restyling.
MozReview-Commit-ID: ApLqaQ3KZ5S
--HG--
extra : rebase_source : 4b4ac2f7f05eaa39181005655a62234275b96ff6
This is a mixture of clang-format and manual restyling.
MozReview-Commit-ID: 6S6yUDXQJtE
--HG--
extra : rebase_source : f7f52bd4c2fe9de1d5b6d99bf2daf841e511d913
This is a mixture of clang-format and manual restyling.
MozReview-Commit-ID: G5ipKb1w5L0
--HG--
extra : rebase_source : 232cae37df4d6d41256c76d0616df5d1c53786fd
This commit removes:
* layout.css.style-attr-with-xml-base.disabled pref
* deprecation XMLBaseAttributeForStyleAttr
* code path for getting base URI of style attr considering xml:base
MozReview-Commit-ID: 1w96eqhHPab
--HG--
extra : rebase_source : 95e33da698ce0cfc9a44de8bc0d63c3fa4634644
This is a mixture of clang-format and manual restyling.
MozReview-Commit-ID: 5wTM0nUeuPK
--HG--
extra : rebase_source : 35f0c24b9dcae5d333a27dbcd29c85a538bb8c0a
This is a mixture of clang-format and manual restyling.
MozReview-Commit-ID: 2cORYQwCeP2
--HG--
extra : rebase_source : 8982e1992290547636db263cd7ff1fadcb8f1b37
This is a mixture of clang-format and manual restyling.
MozReview-Commit-ID: DKyADDJl5G8
--HG--
extra : rebase_source : 0d1d13721d1f88d871ef99e509204fe02464bdec
In this patch, we read the stylo blocklist into nsLayoutUtils's global static
variable during nsLayoutUtils::Initialize(). So, we can decide if we should
fallback to use Gecko backend while updating style backend for a document.
We add "layout.css.stylo-blocklist.blocked_domains" and
"layout.css.stylo-blocklist.enabled" to ContentPrefs.cpp because they are read
very early (during nsLayoutUtils::Initialize).
MozReview-Commit-ID: 8c4n6m9dYD8
--HG--
extra : rebase_source : ca81cd57980d98b9b73f18bb03a8035b161d23ef
