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