This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
FSFindFolder is deprecated as of 10.9 and apparently continues to
work...except for the case of finding the temporary directory when the
user's home directory lives on an NFS mount (!). Using
NSTemporaryDirectory does The Right Thing here, so let's use that instead.
This patch is originally from :baku and updates the seek behaviour of
nsMulitplexInputStream. This fixes an issue with absolute seeking where if a
seek is performed and the correct offset reached, the members of the multiplex
stream were not updated to reflect this.
MozReview-Commit-ID: 7lEvuXxzYkI
--HG--
extra : rebase_source : d86a7ce0fc26abd3c9a60810bd7f7f6346e7a5b0
The lossy conversion to ASCII here can also fail; we should handle that
as well. Rewriting the code to use MakeScopeExit also avoids tangled
logic and/or duplicating calls to ensure the destination string is
truncated on failure.
clang's -Wcomma warning warns about suspicious use of the comma operator such as calling a function for side effects within an expression. Check NS_SUCCEEDED() to use HasMoreElement() in an expression and confirm that it actually returned a legitimate out parameter.
xpcom/io/nsLocalFileUnix.cpp:725:48 [-Wcomma] possible misuse of comma operator here
xpcom/io/nsLocalFileUnix.cpp:1053:39 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: aebrgc5Wqk
--HG--
extra : rebase_source : 18a2bbeb55ff106cdcb88e4889c7fd2745952a31
extra : source : e62ac5b8744d342948ab12f21f369d21f857a706
This improves performance because we won't try to fix the permissions of the file every time the nsIHandlerService implementation wants to open it, and makes it easier to access the file path from xpcshell tests.
MozReview-Commit-ID: DZmLa92qUnZ
--HG--
extra : source : bd0fdce03cc7442079e96318d3a9b519a4d403a9
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
This adds a fallible version of |NS_UnescapeURL| that can be used to
gracefully handle allocation failures when the string needs to be unescaped.
MozReview-Commit-ID: 1eXPzeB2yrI
SHGetKnownFolderPath() is available on Windows Vista+ so we no longer need to GetProcAddress("SHGetKnownFolderPath"). We can set _WIN32_WINNT 0x0600 to expose the SHGetKnownFolderPath function declaration in shlobj.h and call it directly.
Also remove a redundant #include <shlobj.h>.
MozReview-Commit-ID: AoAlrfvQ5AB
--HG--
extra : rebase_source : 2fa3a0d3d122ca31fb3369a43a03b6e2c5d5dec2
When setting WINVER=0x601, we cannot compile SpecialSystemDirectory.cpp due to the following.
0:13.17 c:/Development/hg.mozilla.org/mozilla-inbound/xpcom/io/SpecialSystemDirectory.cpp(123): error C2084: function 'HRESULT SHLoadLibraryFromKnownFolder(const KNOWNFOLDERID &,DWORD,const IID &,void **)' already has a body
0:13.17 C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\um\shobjidl.h(32834): note: see previous definition of 'SHLoadLibraryFromKnownFolder'
0:13.17 c:/Development/hg.mozilla.org/mozilla-inbound/xpcom/io/SpecialSystemDirectory.cpp(158): error C2440: 'initializing': cannot convert from 'HRESULT (__cdecl *)(const KNOWNFOLDERID &,DWORD,const IID &,void **)' to 'HRESULT'
0:13.17 c:/Development/hg.mozilla.org/mozilla-inbound/xpcom/io/SpecialSystemDirectory.cpp(158): note: There is no context in which this conversion is possible
MozReview-Commit-ID: 2KZEzcn21S7
--HG--
extra : rebase_source : b13f2fb11c9e006a83c7d5c3175af001e384b55e
Giving '0' (literal zero) to nsCOMPtr is now ambiguous, as both
nsCOMPtr(decltype(nullptr)) and nsCOMPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: LXiZTu87Ck6
--HG--
extra : rebase_source : f9dcc6b06e9ebf9c30a576f9319f76a51b6dc26f
This keeps the ITEMIDLIST pointers in the "LP" flavour to avoid casting away __unaligned qualifiers. __unaligned is meaningless on non-Itanium platforms but clang-cl nonetheless has trouble with it. (https://llvm.org/bugs/show_bug.cgi?id=30578)
This actually accomplishes what was discussed in the bug and marks any file with the
relevant URI flags as WebDownload, and everything else as OtherDownload.
Note that I'm using DoGetProtocolFlags in order to deal with
nsIProtocolHandlerWithDynamicFlags correctly; while just getting protocol flags
from the IO service directly would be less work, it's technically less correct.
MozReview-Commit-ID: HgD1fV98IEc
--HG--
extra : rebase_source : f114532b48dbca5c83871e61c8d04c719e3b38d1
kLSItemQuarantineProperties was deprecated in 10.10. AFAICT it was replaced by
kCFURLQuarantinePropertiesKey, which was inconveniently new in 10.10.
On my 10.11 machine, the Info.plist fix from the previous patch was not
sufficient to get the data to actually show up when using the old (deprecated)
key. I suspect the setter is a no-op with the old key. So here's code that
uses the new key ("documented" in LSQuarantine.h, where conveniently
the actual properties in the dictionary have kept their keys, but the
dictionary key is now referenced as the CF one).
MozReview-Commit-ID: IMsV6TLrYTP
--HG--
extra : rebase_source : 400db5d7dcbc8fbf165c9e8049376d50001e8f1c
The patch also changes RemoteOpenFileChild::OpenNSPRFileDesc() so that it
cannot succeed with a null fd, so that checking just the return value is
sufficient.
--HG--
extra : rebase_source : cc40bbcf2a9991edc9d3da3fb624d27db50b4996
The patch also makes GetInputStream() fail if the pipe isn't initialized, just
like GetOutputStream().
--HG--
extra : rebase_source : 7391b331ffe25e0ac7ebc755f7da313dc7b5517d
Slightly less than half (93 / 210) of the NS_METHOD instances in the codebase
are because of the use of NS_CALLBACK in
nsI{Input,Output,UnicharInput},Stream.idl. The use of __stdcall on Win32 isn't
important for these callbacks because they are only used as arguments to
[noscript] methods.
This patch converts them to vanilla |nsresult| functions. It increases the size
of xul.dll by about ~600 bytes, which is about 0.001%.
--HG--
extra : rebase_source : c15d85298e0975fd030cd8f8f8e54501f453959b
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
Callers should use a UniquePtr to hold the platform handle.
MozReview-Commit-ID: 6BWnyAf4b3a
--HG--
extra : transplant_source : %26%CA%0D%28%08%9BT%97Z%A1%3Dq%CD%21%A1_%EFE%83%0E
extra : histedit_source : 77f8ed3d0fdec6cce0c95469130ade0fb547bb91
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
ConvertStringLineBreaks calls ConvertUnicharLineBreaksInSitu which uses
fallible allocation. We should make the potential allocation in |BeginWriting|
fallible as well and handle the failure. This also updates the callers to
|ConvertStringLineBreaks| to handle the error properly in release builds.
aOutputLeft is null checked and then dereferenced twice more in this function,
and all callers pass a non-null pointer. So just remove the null check.
--HG--
extra : rebase_source : 8190a51fde8434ac346a4e23db5ed4703762778c
ConvertStringLineBreaks calls ConvertUnicharLineBreaksInSitu which uses
fallible allocation. We should make the potential allocation in |BeginWriting|
fallible as well and handle the failure. This also updates the callers to
|ConvertStringLineBreaks| to handle the error properly in release builds.
This will be used in bug 1273711 to avoid an OOM.
This also tweaks one of the existing overloadings of Base64Encode to return
NS_ERROR_OUT_OF_MEMORY on OOM instead of NS_ERROR_INVALID_ARG.
--HG--
extra : rebase_source : a2ad472b11ac2c858487bf5fdae84d183084773b
The argument naming in Base64.{h,cpp} is horribly confused, with a lot of them
gotten backwards. This patch fixes that, and also introduces a more consistent
naming scheme for arguments and local variables: "binary" is used for binary
data, and "base64" is used for base64-encoded data.
This patch doesn't change any functionality.
--HG--
extra : rebase_source : 7d8a08762e291851bd117a0409fc8715b830fdbe
This is as much a perf issue as it is a UX issue. We should be passing a HWND to
ShellExecuteEx because it can show UI, and that UI should have a proper
parent-child relationship with the Mozilla window. We should do that on the
main thread because of the GUI stuff. OTOH, we want the ShellExecuteEx call to
be a lightweight as possible, hence the SEE_MASK_ASYNCOK flag.
MozReview-Commit-ID: 7VLkWTRWPoe
--HG--
extra : rebase_source : ce16bc0c926a299d9b9103ad0697e3cd07b9157d
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary.
MozReview-Commit-ID: 9AkkAUDMln6
--HG--
extra : rebase_source : 76126361de678729344b0e9eaeac1d523f88ebb4
service. This is needed so that chrome processes know where sandboxed content
processes will be writing their temp files, and so that content processes know
where to write; r?bsmedberg
MozReview-Commit-ID: BK9bTxFGvZO
--HG--
extra : rebase_source : dec290c82fb934ceadc0c9ce0cf87337aa1e8f47