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
Nothing in mozilla-central uses the NS_APP_BOOKMARKS_50_FILE/BMarks key except
tests. It's also not been very useful since the switch to places in ... Firefox
3? so even if addons use it, it's not doing them much good.
BookmarkHTMLUtils.defaultPath returns the same thing anyways for those that
really do insist on getting the equivalent thing (but I'd argue
BookmarkHTMLUtils.defaultPath, as well as the browser.bookmarks.file pref could
just go away as well).
Seamonkey does use NS_APP_BOOKMARKS_50_FILE/BMarks, but they really only need
the #define, which they can add in their source.
Nothing apart the code that was just removed uses those keys, so remove them.
Actually, there is a use in Seamonkey, but considering they're shipping with
omnijar, the code expecting the directory has not been working as designed for
a while, so they can fixup and remove that use as well.
Haik Aftandilian
Kyle Huey
Eric Rahm
Ralph Giles
Nicholas Nethercote
Chris Peterson
Wes Kocher
Andrea Marchesini
Aaron Klotz
Ben Kelly
Kit Cambridge
Stone Shih
Gregory Szorc
Wilmer Paulino
Jeff Lu
Julian Seward
Birunthan Mohanathas
Phil Ringnalda
Sylvestre Ledru
David Rajchenbach-Teller
Sebastian Hengst
Mike Hommey