blob: 857859268b4f16d9ca7956036b1a55c5b0e7a475 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
<!--
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>
|
