The nsGIOService now provides GetAppsForURIScheme which is used to append handlers
for specific scheme in handler list dialog (toolkit/mozapps/handling/content/dialog.js)
and also in Applications section in preferences. In case the default system handler
or user added handler has same name as one of the GIO handlers, the GIO handler
is not appended. The check for not adding handler is by using handler name.
The nsGIOMimeApp class now implements nsIHandlerApp interface. Instead overloaded
GetName methods (nsCString and nsString) we now use nsString variant everywhere.
This require change of nsGNOMERegistry::GetFromType which if fact leads to code
simplification.
The implementation of nsGNOMEShellService::SetDefaultBrowser has been changed
because implementation of CreateAppFromCommand has changed.
The CreateAppFromCommand no longer tries to find the application,
for that FindAppFromCommand has been introduced.
MozReview-Commit-ID: KmfFWRPqV3
--HG--
extra : source : 9660ff09c2212cb7456e50cb166752f42e0a0669
extra : amend_source : 3c5fc61fe09b9b68bdfbb9683335cedd4d706744
The nsGIOService now provides GetAppsForURIScheme which is used to append handlers
for specific scheme in handler list dialog (toolkit/mozapps/handling/content/dialog.js)
and also in Applications section in preferences. In case the default system handler
or user added handler has same name as one of the GIO handlers, the GIO handler
is not appended. The check for not adding handler is by using handler name.
The nsGIOMimeApp class now implements nsIHandlerApp interface. Instead overloaded
GetName methods (nsCString and nsString) we now use nsString variant everywhere.
This require change of nsGNOMERegistry::GetFromType which if fact leads to code
simplification.
The implementation of nsGNOMEShellService::SetDefaultBrowser has been changed
because implementation of CreateAppFromCommand has changed.
The CreateAppFromCommand no longer tries to find the application,
for that FindAppFromCommand has been introduced.
MozReview-Commit-ID: KmfFWRPqV3
--HG--
extra : rebase_source : 36d254cbc45cbe6929cc469cd531211f7ddd6a64
There are non-cost reference return values on IPDL structs. We should take
advantage of them in order not to recopy everything everytime something
changes.
MozReview-Commit-ID: D4hG2moE3f
--HG--
extra : rebase_source : 4edca9b1a808f99dd60be908bbb197757bf9b90a
It would be really nice to push all of this back up to the parent or to at
least make it asynchronous. I think it should be possible since we control
when we send the DOM events, but for the moment this should work.
With this patch, I extend ProxyMIMEInfo and HandlerInfo with information about
the available extensions for a given MIME type. On Linux, at least, we read
the system (in my case GNOME) registry in the child and handlers.json in the
parent finally merging them again in the child (in
ContentHandlerService::FillHandlerInfo). Even though I was unable to get my
mochitest to work, it did work well enough that I could verify that this patch
was getting all of the proper extensions to the nsContentAreaDragDrop.cpp
code.
MozReview-Commit-ID: AR3VayMUiDN
--HG--
extra : rebase_source : f9861e46e92fb7e8d297eff3e5d61a3c18912b47
Non ns-prefixed classes are supposed to be in either the mozilla namespace or
a sub namespace (such as dom, css, or others).
MozReview-Commit-ID: 8bF6bP49NLG
--HG--
extra : rebase_source : bfa5e6da36c49ea7bb333eb58d168ef614c07c0b
This patch adds a new diagnostic status flag to nsIWebProgressListener,
STATE_CERT_DISTRUST_IMMINENT, which indicates that the certificate chain is
going to change validity due to an upcoming distrust event. The first of
these events is this bug, affecting various roots from Symantec.
The STATE_CERT_DISTRUST_IMMINENT flag is set by nsNSSCallbacks and passed,
via nsSecureBrowserUIImpl, to browser.js where it is used to alert the console.
Adding this sort of diagnostic printing to be accessible to browser.js is a
long-desired goal, as future functionality can start doing more decision-making
there. We may, for example, also want to degrade the lock icon, which will be
straightforward with this flag.
This commit does not implement the IsCertificateDistrustImminent method. That is
follow-on work.
MozReview-Commit-ID: 75IOdc24XIV
--HG--
extra : rebase_source : e6a95d0be65f667eff0b131274272f0df91f8732
This adds a global instance that can be used by invoking assertion methods directly on the imported Assert object. The test suites set the global reporter function to the one for the currently running test.
MozReview-Commit-ID: 8dksVc9o7r
--HG--
extra : rebase_source : 3e382c6d24c6019d29963811c37469cfc23b928f
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
The nsExternalHelperAppService has been changed to ask for application in case
the preferred application has not been found (to cover the case the user has
uninstalled the application).
MozReview-Commit-ID: 63AFzPhzcxN
--HG--
extra : rebase_source : f91bdae686b062bade1cacdb489c935e30ea0876
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
In order to optionally report the full hash back to Google, we need to keep it
around in the callback. While a prefix is not the same as a full hash (multiple
full hashes can map to the same prefix), in this case, the callback will only be
called when the full hash matches.
MozReview-Commit-ID: F4WSLZpYrXB
--HG--
extra : rebase_source : da3b16b00729d0aa6ff1765a135b751fcf44c012
ISO C++ forbids converting a string constant to 'wchar_t*' [-Werror=write-strings]
Either change it to a nullptr (which has same intent) or pass through a static
MozReview-Commit-ID: CSunOCyO9PN
--HG--
extra : rebase_source : bfdabc1f463eca75987c6561f7c3ea60acf0340f
I had a theory about what was happening (that we're somehow closing the window
between the attempt to open the channel and the resulting OnStartRequest), but
when I attempted to test that I couldn't make it crash (in fact, closing the
window calls Cancel on the stream and stops the OnStartRequest from
happening). So, I don't know what's causing this, but clearly we're failing to
get a TabChild out, so let's stop crashing for the time being.
MozReview-Commit-ID: LeGJCvh26dm
--HG--
extra : rebase_source : 2a3e97e7500b988a3fba5dae63be96caf180ab9f
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
Asynchronously load handlers.json for nsHandlerService-json.js in
order to avoid blocking IO early on.
MozReview-Commit-ID: F3THSxvXR7I
--HG--
extra : rebase_source : 95d5ccb545cd7d8a09f80586fc2bf2dcf1ea5ab7
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is used in ways that rely on the implicit conversion
to |char*|. The patch uses get() and EqualsLiteral() calls to replace the
implicit conversions.
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is only used in ways that nsCStrings can also be used
(i.e. no null checks or implicit conversions to |char*|).
In every case the patch trivially replaces the nsXPIDLCString with an
nsCString. (Also, there are a couple of unused nsXPIDLCString variables that
the patch simply removes.)
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
This mechanically replaces nsILocalFile with nsIFile in
*.js, *.jsm, *.sjs, *.html, *.xul, *.xml, and *.py.
MozReview-Commit-ID: 4ecl3RZhOwC
--HG--
extra : rebase_source : 412880ea27766118c38498d021331a3df6bccc70
nsIURI.originCharset had two use cases:
1) Dealing with the spec-incompliant feature of escapes in the hash
(reference) part of the URL.
2) For UI display of non-UTF-8 URLs.
For hash part handling, we use the document charset instead. For pretty
display of query strings on legacy-encoded pages, we no longer care to them
(see bug 817374 comment 18).
Also, the URL Standard has no concept of "origin charset". This patch
removes nsIURI.originCharset for reducing complexity and spec compliance.
MozReview-Commit-ID: 3tHd0VCWSqF
--HG--
extra : rebase_source : b2caa01f75e5dd26078a7679fd7caa319a65af14
This is similar like the previous patch, but for the 8-bit string variants.
Also, it changes assignment to Adopt() in GetCString() and GetDefaultCString()
to avoid an extra copy.
--HG--
extra : rebase_source : eba805c3a7b809d5ccd6e853b1c9010db9477667
This is basically a cosmetic change; references are the normal way to do string
outparams.
--HG--
extra : rebase_source : ffc5945f269bdcd3d4116755b56713e87a44b6cd
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
It's hard to know exactly what's going on in this testcase because we nest a
bunch of calls. I was unable to observe the crash myself, but it appears that
part of it (at least) has to do with the test timing out and causing the
opened page to get closed by the harness. I believe this causes us to fail to
getInterface to the docShell for the now-closed window and we crash.
There isn't much we can do in this situation so, let's try being defensive and
watch crash-stats.
MozReview-Commit-ID: EeSUqMPXk58
--HG--
extra : rebase_source : 44758e1f0eabfe0b02b654dd48317f320b79a217
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
nsExternalHelperAppService::OnStartRequest calls MaybeCloseWindow
unconditionally after it finishes looking at the request headers. The call
from DidDivertRequest is redundant (and possibly left over from when we didn't
call OnStartRequest properly).
MozReview-Commit-ID: Cm5YhCt5XLY
--HG--
extra : rebase_source : 628100c860459d338cbabc65f557d7058b91f26d
