I accidentally broke the ability to retrieve a big string from the
clipboard, and there was no test that failed. So this provides a new
test that does the following:
1. Store a big string in a nsTransferable.
2. Copy it to the clipboard.
3. Create a new nsTransferable, initialize with small data.
4. Populate the nsTransferable with (big) data from the clipboard.
5. Populate the nsTransferable with small data.
After each step, the test checks whether the transferable holds the
expected data and length, and (on non-Windows) checks that the big
data is backed by a file, and small data is not.
MozReview-Commit-ID: 9yuXZxVqD6R
--HG--
extra : rebase_source : 6cec638c59e8ce5a18adbb642779c1dcd457cc5b
- Count open file descriptors instead of testing the existence of a file
(because the clipboard is now only reachable through file descriptors,
and not through a file path).
- Use a fixed string instead of a random string. The previous way of
generating a string was non-deterministic, and there was a very small
chance that the generated string was not large enough to trigger the
cache-to-disk-mode.
MozReview-Commit-ID: KOkYOm280Oh
--HG--
extra : rebase_source : 32f1eb0c5beb4f8ebb1728bda481ded21247e0ec
This patch mitigates violation of private browsing disk access. The DataStruct API and implementation is modified to obey private browsing design when used by objects such as nsTransferable (during clipboard data caching for example.)
Without this patch, a user is misled by use of private browsing when copying (or in some case just selecting) large blocks of text. A condition (presently hard coded at one million bytes kLargeDatasetSize) produces a cache file on disk regardless of whether private browsing is in use. This violates Mozilla's design (documented online at https://support.mozilla.org/kb/private-browsing-browse-web-without-saving-info/ and https://wiki.mozilla.org/PrivateBrowsing) This patch simply corrects the violation, discovered and resolved by the Tor Browser community.