gecko-dev/dom/indexedDB/test/test_filehandle_truncate_exceptions.html

48 lines
1.8 KiB
HTML

<!--
Any copyright is dedicated to the Public Domain.
http://creativecommons.org/publicdomain/zero/1.0/
-->
<html>
<head>
<title>File Handle Test</title>
<script src="/tests/SimpleTest/SimpleTest.js"></script>
<link rel="stylesheet" type="text/css" href="/tests/SimpleTest/test.css"/>
<script type="text/javascript">
async function testSteps() {
const name = window.location.pathname;
// Test setup begin
const fileHandle = await createReadWriteFileWithInitialContent(name, getBuffer(1));
// Test setup end
// Since TypeError is very generic, we also check the exception message.
// XXX If we add [EnforceRange] to IDBFileHandle.truncate, this will fail before truncate is called,
// and since UINT64_MAX is larger than Number.MAX_SAFE_INTEGER, we have no way to reliably test it,
// probably.
// XXX This restriction might go away once the use of UINT64_MAX as a special value is removed.
info("Expecting TypeError on truncating to a negative length that converts to UINT64_MAX implicitly");
let message = assertThrowsInstanceOf(() => { fileHandle.truncate(-1); }, TypeError);
is(message, "IDBFileHandle.truncate: UINT64_MAX is not a valid size", "Correct message");
info ("Attempt to truncate to a size larger than the current size should fail.");
// XXX Expect a more specific error here?
await expectingError(fileHandle.truncate(10000000), "UnknownError");
info("Still the state should be consistent and we should be able to truncate to a valid size after this.");
// This wasn't always the case, see Bug 1626973
await expectingSuccess(fileHandle.truncate(0));
}
</script>
<script type="text/javascript" src="file.js"></script>
<script type="text/javascript" src="helpers.js"></script>
</head>
<body onload="runTest();"></body>
</html>