Cleanup of all localization notes that refer to entities
that are not listed in the corresponding localization file.
MozReview-Commit-ID: Bl0VU9HoPfa
--HG--
extra : rebase_source : 86680b8ae037783304f045e94c7af7053a0f69e9
... even if all the addresses are identical.
Otherwise the IsTRR() bit would be dropped, resulting in
about:networking showing false for this entry while in reality being
TRR. Or vice versa.
MozReview-Commit-ID: JABLm09iCnn
--HG--
extra : rebase_source : 24f9ff8b6818c00359069add23d1354ab2f1b1f9
Adds a new TYPE_SPECULATIVE to nsIContentPolicy uses it as the type for
speculative connection channels from the IO service. I believe I've added it to
all the content policies in tree to make sure it behaves the same as TYPE_OTHER
used to.
The webextension test shows that the webextension proxy API sees speculative
lookups requested through the IO service.
MozReview-Commit-ID: DQ4Kq0xdUOD
--HG--
extra : rebase_source : d9460fdac118bc68f0db79749a16f181b580f2e7
The DNS service was shutdown and restarted again in several scenarios,
for example when one of its prefs changed and by nsIOService when going
offline/online. The DNSService restart dragged the resolver, TRRService
and others with it and they too were thus restarted.
Most notably this hurt TRR resolving, as the restart caused short gaps
in time when there was no TRRService available and nsHostResolver
defaults to TRR Mode "native" if there's no TRRservice up, causing the
name resolver to occasionally use the wrong or unexpected resolver even
though TRR is enabled.
The resolver restart also flushed the DNS cache which is now avoided.
It is also a performance gain.
MozReview-Commit-ID: pp4Y8bNQJk
--HG--
extra : rebase_source : 9e3b3e6c0df16b8ca6287d8045f594026ae9ad6d
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 65bac47c2cd1a20b3c675a01b44a25a1d2d3ab7a
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 6f7d4fd1d6cdea2c14866705a2dc972eb5f43382
There seems to be no reason to conditionally fire the cookie-db-read event. Currently it is not fired if no cookies were read. There seems to be only one other consumer of this event (a test) which should work fine if the event were fired every time. This change would eliminate a particularly ugly workaround in cookie-related policy testing.
MozReview-Commit-ID: FbD1cvsBZBO
--HG--
extra : rebase_source : 6611debb3567310c61e5a5dc9cedadeae888cfe5
There seems to be no reason to conditionally fire the cookie-db-read event. Currently it is not fired if no cookies were read. There seems to be only one other consumer of this event (a test) which should work fine if the event were fired every time. This change would eliminate a particularly ugly workaround in cookie-related policy testing.
MozReview-Commit-ID: FbD1cvsBZBO
--HG--
extra : rebase_source : ff5049f36c7f3df3ad182ebb1a6ccc5db1032e23
NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
This patch moves all TLS error string handling to the frontend.
Dev-tools doesn't show the same error code as the page does anymore but only the error code as string.
All logging of these error messages has been removed.
Bug #: 1415279
Differential Revision: https://phabricator.services.mozilla.com/D607
--HG--
extra : rebase_source : 61e2d94cb21ef4c02b81448531609205c85a9707
Currently VarCache prefs are setup in two parts:
- The vanilla pref part, installed via a data file such as all.js, or via an
API call.
- The VarCache variable part, setup by an Add*VarCache() call.
Both parts are needed for the pref to actually operate as a proper VarCache
pref. (There are various prefs for which we do one but not the other unless a
certain condition is met.)
This patch introduces a new way of doing things. There is a new file,
modules/libpref/init/StaticPrefList.h, which defines prefs like this:
> VARCACHE_PREF(
> "layout.accessiblecaret.width",
> layout_accessiblecaret_width,
> float, 34.0
> )
This replaces both the existing parts.
The preprocessor is used to generate multiple things from this single
definition:
- A global variable (the VarCache itself).
- A getter for that global variable.
- A call to an init function that unconditionally installs the pref in the
prefs hash table at startup.
C++ files can include the new StaticPrefs.h file to access the getter.
Rust code cannot use the getter, but can access the global variable directly
via structs.rs. This is similar to how things currently work for Rust code.
Non-VarCache prefs can also be declared in StaticPrefList.h, using PREF instead
of the VARCACHE_PREF.
The new approach has the following advantages.
+ It eliminates the duplication (in all.js and the Add*VarCache() call) of the
pref name and default value, preventing potential mismatches. (This is a real
problem in practice!)
+ There is now a single initialization point for these VarCache prefs.
+ This avoids need to find a place to insert the Add*VarCache() calls, which
are currently spread all over the place.
+ It also eliminates the common pattern whereby these calls are wrapped in a
execute-once block protected by a static boolean (see bug 1346224).
+ It's no longer possible to have a VarCache pref for which only one of the
pieces has been setup.
+ It encapsulates the VarCache global variable, so there is no need to declare
it separately.
+ VarCache reads are done via a getter (e.g. StaticPrefs::foo_bar_baz())
instead of a raw global variable read.
+ This makes it clearer that you're reading a pref value, and easier to
search for uses.
+ This prevents accidental writes to the global variable.
+ This prevents accidental mistyping of the pref name.
+ This provides a single chokepoint in the code for such accesses, which make
adding checking and instrumentation feasible.
+ It subsumes MediaPrefs, and will allow that class to be removed. (gfxPrefs is
a harder lift, unfortunately.)
+ Once all VarCache prefs are migrated to the new approach, the VarCache
mechanism will be better encapsulated, with fewer details publicly visible.
+ (Future work) This will allow the pref names to be stored statically, saving
memory in every process.
The main downside of the new approach is that all of these prefs are in a
single header that is included in quite a few places, so any changes to this
header will cause a fair amount of recompilation.
Another minor downside is that all VarCache prefs are defined and visible from
start-up. For test-only prefs like network.predictor.doing-tests, having them
show in about:config isn't particularly useful.
The patch also moves three network VarCache prefs to the new mechanism as a
basic demonstration. (And note the inconsistencies in the multiple initial
values that were provided for
network.auth.subresource-img-cross-origin-http-auth-allow!) There will be
numerous follow-up bugs to convert the remaining VarCache prefs.
MozReview-Commit-ID: 9ABNpOR16uW
* * *
[mq]: fixup
MozReview-Commit-ID: 6ToT9dQjIAq
It seem that only nsStandardURL and nsSimpleURI (and classes that inherit them) do not have threadsafe refcounting yet.
MozReview-Commit-ID: J8gLoBSPCTl
--HG--
extra : rebase_source : 0e1659c28b18909e31b2e3e74baf74edf1e100c8
* Removes mSpecEncoding since the spec is always ASCII encoded
* nsStandardURL::InitGlobalObjects is now called from nsNetStartup
* Removes prefObserver from nsStandardURL
* mDisplayHost is now initialized every time that we change the hostname
* Adds locking to the gAllURLs list
MozReview-Commit-ID: 93mwECxYxWl
* * *
[mq]: overfix
MozReview-Commit-ID: 98nyTYa5ZeR
--HG--
extra : rebase_source : 82045e10771038d7168d1f235143c24c72dd5a45
The change from "docShell" to "mDocShell" for the SetName call in the
OwnerIsMozBrowserFrame case in nsFrameLoader::MaybeCreateDocShell is a
drive-by correctness fix for a bug the rename of "docShell" to "parentDocShell"
caught: setting the name of our _parent_ docshell based on the name attr of our
owner makes no sense.
MozReview-Commit-ID: DwnWt8jTokV
* blobImpl references are now only kept in nsHostObjectProtocolHandler
* removes nsHostObjectProtocolHandler.idl
* Makes nsHostObjectURI no longer inherit from nsSupportsWeakReference
MozReview-Commit-ID: AC1klrfsMnn
--HG--
extra : rebase_source : 142802f9a6fa6aae5611dccf117d88f96a9985a6
This isn't strictly related, but I ran into it for the nth time while updating
tests, and I got fed up with having my tests fail with a useless numeric value
with no indication of where it came from.
MozReview-Commit-ID: 6OjgVYw7tNd
--HG--
extra : rebase_source : 259667d2a26ec4252a0f8a097ca35b3b702b17a0
extra : histedit_source : 492f541471b896a9a4b941baad2b14de8faf9113
* This is needed in order to make the constructors of URI implementations private
MozReview-Commit-ID: 8dddDXbmrfF
--HG--
extra : rebase_source : b8e471d228617ae4bd07c5ed6317951c06ce8d56
BackgroundFileSaver holds a reference to its nsIBackgroundFileSaverObserver
(observer). If such an observer has an enclosure that captures the
BackgroundFileSaver itself (as in test_backgroundfilesaver.js), this causes a
cycle that won't be caught by the cycle collector. Thus, we have to manually
break the cycle when we're done with the observer (in
BackgroundFileSaver::NotifySaveComplete). Note that this currently relies on the
fact that this implementation requires that Finish always be called (see remarks
in nsIBackgroundFileSaver.idl).
MozReview-Commit-ID: GOO9q2vFRso
--HG--
extra : rebase_source : f62b0ec513e0b681da3e76c0af31077d2fa03fea
extra : amend_source : 2b3a11d4b17df10705bad38e02b6ce130b456448
The initialization path for the SOCKS proxy in firefox involves creating
a generic AF_INET socket, and then replacing it if the actual
configuration requires something else (either AF_INET6 or AF_LOCAL).
With syscall filtering configured to return an error in the event of
AF_INET or AF_INET6 socket creation, this initialization path fails. We
would like this capability so that we can prevent firefox from making
network requests outside of the Tor proxy.
This patch adds a check in the initial socket creation path to see if
the SOCKS proxy host begins with file:// with the assumption that such
URIs point to a UNIX Domain Socket (on Linux+macOS only). In that case,
we create an AF_LOCAL socket rather than the requested type. A similar
check for Windows already exists to determine if the proxy is actually a
named pipe.
In the subsequent replacing step no work occurs as the passed in socket
matches the type we need, so no changes need to be made there.
NOTE: With this change there is still a one-time request for an AF_INET6
socket that occurs. This code path exists to determine whether the
system supports IPv6; if socket(AF_INET6...) fails then it is assumed
that the system does not. However, this check only affects code that is
unreachable when using AF_LOCAL sockets so it seems safe leave as it is.
However, this does mean that firefox will still be incompatible with
seccomp policies which kill the calling thread in the event of a
socket(AF_INET6,...) call.
... as they otherwise appear in the about:networking list as "false"
while having been resolved by TRR.
MozReview-Commit-ID: 9g9fUExvyjS
--HG--
extra : rebase_source : 3098b7c3f7d01e55f5a8c031fc6a73e53f7edb05
... to avoid a catch-22 as CP needs name resolve to work.
MozReview-Commit-ID: DC1CjlUy4cJ
--HG--
extra : rebase_source : 3bc0f146071f04757d44b76f352e48b2abb4dad0
* 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
* 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 are the only occurrences of "browser.cache.use_new_backend" in the tree.
MozReview-Commit-ID: IOSw0uUD5FW
--HG--
extra : rebase_source : c6c7e6abfdf2c3ff23c1f18e36110781f6b5580b
The original code (from bug 1200802) declared an XPCOM object as a static bare
pointer, which for future reference is probably never the right thing to do. It
might have worked if it was cleared before shutdown but it never was.
MozReview-Commit-ID: EMe7wgzm6zv
--HG--
extra : rebase_source : 572ce6822e297692bab3311a65e1143785b913c4
Previously it would store the time even for early AAAA responses that
weren't used until the A response came in, thus getting the timing
wrong.
MozReview-Commit-ID: KctUjMjH5FR
--HG--
extra : rebase_source : fafd7ad25cd1b7a43d4b4a5653600cad830b471d
To prevent it from sitting waiting for an event that was sent before the
TRRService started.
MozReview-Commit-ID: 9F0IlWGdA9O
--HG--
extra : rebase_source : 6a70210a4e538d8a1b240684a0b3ed5fed38e6ad
There's no need to allocate a completely new nsCString when all we want
to do is parse a character string into an integer. We can allocate a
dependent string instead, which will avoid some memory churn.
Otherwise it will just load back the same (problematic) addresses from the
cache again the second time. This introduces a new resolver bit
(REFRESH_CACHE) that also invalidates the existing cache entry while doing the
new resolve.
MozReview-Commit-ID: 5Bc2KiAGYYA
--HG--
extra : rebase_source : ae368c88a5db27f0980b9928439d27588bc84815
What we're really doing in CacheEntry::CheckRequest is checking:
a) Whether the method is contained in our allowed methods; and
b) Whether all of the headers are contained in our allowed headers.
nsTArray lets us check directly for containing elements, so let's use
that facility rather than rolling our own.
nsCaseInsensitiveCStringComparator ought to be cheap to construct, but
the object actually has a vtable to install and whatnot. So it's
beneficial to pull the construction of it outside of the headers loop.
The entries in mMethods and mHeaders aren't sorted in any special way,
so we can remove expired entries using UnorderedRemoveElementAt, which
is faster than RemoveElementAt.
DNSRequestChild's constructor takes `const nsCString&` parameters. If
you have a `const nsACString&` argument to pass in to the constructor,
you're forced to construct a temporary nsCString object to satisfy the
prototype. But the temporary string will just get copied inside the
constructor and you'll have to destroy the temporary string object you
created.
Let's skip all this, and just have DNSRequestChild take `const
nsACString&` arguments instead, and avoid the temporary object.
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
mCleanedUp is a VarCache variable, which mirrors the canonical value of the
network.predictor.cleaned-up pref. When the canonical pref value is modified,
e.g. by SetBool(), then mCleanedUp is also updated.
But the updating relationship is one-way -- if mCleanedUp is modified, the
canonical value of the pref is not updated. Such an inconsistency is bad! For
example, Predictor.cpp will use mCleanedUp's value, but about:config will show
the canonical value.
(For this reason, VarCache prefs are meant to be read-only outside of libpref.
Bug 1436655 will enforce this.)
This patch changes mCleanedUp so it's not a VarCache variable, avoiding the
mirroring issue.
MozReview-Commit-ID: LIG02gMkRjF
--HG--
extra : rebase_source : 273b2372ce718b0f346695a0dc96a189cd3ba233
Older versions of clang complain about this code, with:
netwerk/protocol/http/nsCORSListenerProxy.cpp:230:5: error: default initialization of an object of const type 'const struct CheckHeaderToken' without a user-provided default constructor
Later versions of the standard were amended to make this not an error,
but clang still warns. Pacify clang by making the object not const.
WebPlatformTests expect that when calling
url.host = "host:" // port missing
url.host = "host:65536" // port too big
url.host = "host:bla" // invalid port
that the hostname will be set, but the port will be left unchanged.
Since DOM APIs are the only consumers for SetHostPort it means we can change this behaviour to match the WPT expectations.
As such, SetHostPort will return NS_OK if setting the host succeded, and will ignore if setting the port failed.
MozReview-Commit-ID: LoMw8hCWlCv
--HG--
extra : rebase_source : db28b73d98060c2f66f899afe1a4ae26f4db85db
We normally fail in nsStandardURL::SetPassword if the username is empty.
But if the password we are trying to set is also empty, we should't really fail.
MozReview-Commit-ID: FIDqkPrb1gp
--HG--
extra : rebase_source : 9080c44e91e27acd210f3ace3a234528513928c3
* Code in XMLHttpRequestMainThread is converted to set the username and password individually. This is because when the parameters are empty, it ended up calling SetUserPass(":") which always returns an error.
MozReview-Commit-ID: 3cK5HeyzjFE
--HG--
extra : rebase_source : f34400c11245d88648b0ae9c196637628afa9517
Calling NS_ENSURE_SUCCESS at the begining of the methods shows the error in the console, but what we really care about is where the error code comes from. So it is best to use if (NS_FAILED(mStatus) {} at the begining of the methods, and NS_ENSURE_SUCCESS right after calling the appropriate method on mMutator.
MozReview-Commit-ID: 5vVuHk3N4FU
--HG--
extra : rebase_source : f477f0f87b3303422a595f27d9b39ac25335d701
* Removes setHostAndPort from nsIURIMutator as it only has one use
* Instead, the consumer sets the port to -1 before calling setHostPort()
MozReview-Commit-ID: Jx9UMW440hq
--HG--
extra : rebase_source : cb60e76c905db6bb308ddfd8fa548cc13d3afe06
