Large clipboard data (in nsTransferable) in content processes is no
longer stored in a temporary file, but kept in memory.
Differential Revision: https://phabricator.services.mozilla.com/D10336
Right now CreateDataFromPrimitive doesn't use the aDataLen parameter, and after this change the out
value should be the same as the value passed in, as long as we are dealing with strings.
Differential Revision: https://phabricator.services.mozilla.com/D10718
--HG--
extra : moz-landing-system : lando
This combines some of your ideas from D8074, in which I think is quite a big improvement to the overall code.
The code for nsTransferable::GetTransferData, especially nsIFlavorDataProvider is a bit wonky, because I tried to preserve the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D9599
--HG--
extra : moz-landing-system : lando
This combines some of your ideas from D8074, in which I think is quite a big improvement to the overall code.
The code for nsTransferable::GetTransferData, especially nsIFlavorDataProvider is a bit wonky, because I tried to preserve the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D9599
--HG--
extra : moz-landing-system : lando
Running clang-format makes this code at least a bit more pleasant to look at.
Differential Revision: https://phabricator.services.mozilla.com/D8074
--HG--
extra : moz-landing-system : lando
DataStruct cannot safely be copied if its mCacheFD member is set.
Currently there is no code for this case, but to avoid problems later,
mark the copy and assignment constructors private and delete them.
A move-constructor was added to compensate for the deleted copy
constructor. nsTransferable::AddDataFlavor uses this new constructor
instead of the previous implicit default copy constructor.
MozReview-Commit-ID: 3N5xjFXOUKB
--HG--
extra : rebase_source : dc609f20c7048b3630fa99fe2deef3f5be155334
Ensure that only DataStruct::mData + mDataLen, XOR
DataStruct::mCacheFD is used.
(Previously it was possible that all of these members were populated,
which is a waste of memory.)
The effect of this change is visible when SetTransferData is called
multiple times with the same flavor, but with one below the threshold
for storing in-memory, and the other above (=store in a file).
MozReview-Commit-ID: 4UlkKAYsjf
--HG--
extra : rebase_source : 75398f84f039bdf2ff0195342f3db8efbdce6d3d
The cache file is never directly exposed to consumers of DataStruct,
so it does not make sense to keep the clipboardcache file around
forever.
The only change in this commit is to switch from using a filename to
using a file descriptor. In the destructor, the FD is explicitly closed
(which releases the file data). nsAnonymousTemporaryFile takes care
of removing the file when the destructor is not called (e.g. crashes).
Previously, the clipboard cache was stored in a file called:
TmpD/clipboardcache-N
As of this commit, the clipboard cache is stored at:
TmpD/mozilla-temp-randomN (macOS and Linux)
TmpD/mozilla-temp-files/mozilla-temp-randomN (Windows)
(see xpcom/io/nsAnonymousTemporaryFile.{h,cpp} for more details)
To verify that these files are really gone:
1. Create a document with 500k+ characters, open it in Firefox.
2. Copy its content - this will trigger the clipboard cache.
3. Look for the open file descriptor of the deleted file:
( macOS and Linux: )
lsof +L1 | grep mozilla-temp
4. Copy anything (under the 500k threshold), or quit/kill Firefox.
5. Repeat step 3 and observe that the number of file descriptors
has decreased.
MozReview-Commit-ID: 85GlKQrNUl5
--HG--
extra : rebase_source : 6937143639d6a6280ffe8b53b4c2fa4b1e7ef55d
We shouldn't assume it's safe to write to /tmp unless we know
for sure we are not in a private browsing window. So
use mPrivateData = true as default.
Based on a patch by Neill Miller:
https://trac.torproject.org/projects/tor/ticket/21830
Ensure that only DataStruct::mData + mDataLen, XOR
DataStruct::mCacheFD is used.
(Previously it was possible that all of these members were populated,
which is a waste of memory.)
The effect of this change is visible when SetTransferData is called
multiple times with the same flavor, but with one below the threshold
for storing in-memory, and the other above (=store in a file).
MozReview-Commit-ID: 4UlkKAYsjf
--HG--
extra : rebase_source : fff484301dc87f12685575084993b6bf877f9a9b
The cache file is never directly exposed to consumers of DataStruct,
so it does not make sense to keep the clipboardcache file around
forever.
The only change in this commit is to switch from using a filename to
using a file descriptor. In the destructor, the FD is explicitly closed
(which releases the file data). nsAnonymousTemporaryFile takes care
of removing the file when the destructor is not called (e.g. crashes).
Previously, the clipboard cache was stored in a file called:
TmpD/clipboardcache-N
As of this commit, the clipboard cache is stored at:
TmpD/mozilla-temp-randomN (macOS and Linux)
TmpD/mozilla-temp-files/mozilla-temp-randomN (Windows)
(see xpcom/io/nsAnonymousTemporaryFile.{h,cpp} for more details)
To verify that these files are really gone:
1. Create a document with 500k+ characters, open it in Firefox.
2. Copy its content - this will trigger the clipboard cache.
3. Look for the open file descriptor of the deleted file:
( macOS and Linux: )
lsof +L1 | grep mozilla-temp
4. Copy anything (under the 500k threshold), or quit/kill Firefox.
5. Repeat step 3 and observe that the number of file descriptors
has decreased.
MozReview-Commit-ID: 85GlKQrNUl5
--HG--
extra : rebase_source : b0c6e9540e53ad5e713a9db55f3001d7f53c308a
Ensure that only DataStruct::mData + mDataLen, XOR
DataStruct::mCacheFD is used.
(Previously it was possible that all of these members were populated,
which is a waste of memory.)
The effect of this change is visible when SetTransferData is called
multiple times with the same flavor, but with one below the threshold
for storing in-memory, and the other above (=store in a file).
MozReview-Commit-ID: 4UlkKAYsjf
--HG--
extra : rebase_source : c9a5a7a3f5a6f3e6ab1bfb8662372cbbac837a00
The cache file is never directly exposed to consumers of DataStruct,
so it does not make sense to keep the clipboardcache file around
forever.
The only change in this commit is to switch from using a filename to
using a file descriptor. In the destructor, the FD is explicitly closed
(which releases the file data). nsAnonymousTemporaryFile takes care
of removing the file when the destructor is not called (e.g. crashes).
Previously, the clipboard cache was stored in a file called:
TmpD/clipboardcache-N
As of this commit, the clipboard cache is stored at:
TmpD/mozilla-temp-randomN (macOS and Linux)
TmpD/mozilla-temp-files/mozilla-temp-randomN (Windows)
(see xpcom/io/nsAnonymousTemporaryFile.{h,cpp} for more details)
To verify that these files are really gone:
1. Create a document with 500k+ characters, open it in Firefox.
2. Copy its content - this will trigger the clipboard cache.
3. Look for the open file descriptor of the deleted file:
( macOS and Linux: )
lsof +L1 | grep mozilla-temp
4. Copy anything (under the 500k threshold), or quit/kill Firefox.
5. Repeat step 3 and observe that the number of file descriptors
has decreased.
MozReview-Commit-ID: 85GlKQrNUl5
--HG--
extra : rebase_source : eb05c1d4600f62373aa1b7e472154b57b99e6bf8
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
This converts |nsITransferable.flavorsTransferableCanExport| and
|nsITransferable.flavorsTransferableCanImport| to return a |nsIArray|.
|nsIFormatConverter.getInputDataFlavors| and
|nsIFormatConverter.getOutputDataFlavors| are updated as well.