2011-10-11 05:46:43 +09:00
|
|
|
<!DOCTYPE html>
|
2012-09-01 07:48:21 +09:00
|
|
|
<!--
|
2015-05-15 21:02:56 +09:00
|
|
|
Copyright 2015 Mozilla Foundation
|
2012-09-01 07:48:21 +09:00
|
|
|
|
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
you may not use this file except in compliance with the License.
|
|
|
|
|
You may obtain a copy of the License at
|
|
|
|
|
|
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
|
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
See the License for the specific language governing permissions and
|
|
|
|
|
limitations under the License.
|
|
|
|
|
-->
|
Initial import of first test harness
The harness (test.py) operates as follows. First it locates executable browsers
(or symlinks or scripts) named "[browser][version]", e.g. "firefox4".
It then launches the located browsers and asks them to load the file
test_slave.html. At the same time, test.py sets up an HTTP server on
localhost:8080 (there's a race condition here currently ;). After
test_slave loads in the browser(s), it fetches the task manifest
(test_manifest.json). The entries in the manifest specify which PDF
to load and how many times to cycle through page rendering. This will
probably evolve over time. test_slave then performs the requested
tasks and POSTs the results back to test.py, which saves them. When
all the results of for a task are in, test.py checks them.
There are three types of tests currently. "==" tests compare the
rendering of a PDF against a master copy. This is not yet implemented
because setting up a master copy is complicated. "fbf" tests render
all a PDF's pages, then go back to page 1 and render all pages a
second time. The renderings from the first round must match the ones
from the second round. "load" tests just check that a PDF's pages
load without errors.
Currently the test harness will only launch a "firefox4" target. This
can be a bash script in your pdf.js checkout, pdf.js/firefox4,
something like the following
#!/bin/bash
dist="/path/to/firefox4/installation"
profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'`
$dist/firefox -no-remote -profile $profile $*
rm -rf $profile
(Yes, this script doesn't clean up properly on early termination.)
It's possible to run the tests in a normal browsing session, but that
might be annoying. With that set up, run the harness like so
python test.py
If all goes well, you'll see all "TEST-PASS" messages printed to
stdout. If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL"
printed to stdout.
2011-06-19 10:09:21 +09:00
|
|
|
<html>
|
2011-10-11 05:46:43 +09:00
|
|
|
<head>
|
2015-05-15 21:02:56 +09:00
|
|
|
<title>PDF.js test slave</title>
|
|
|
|
|
<meta charset="utf-8">
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 20:00:10 +09:00
|
|
|
<script src="../build/generic/build/pdf.mjs" type="module"></script>
|
|
|
|
|
<script src="../build/components/pdf_viewer.mjs" type="module"></script>
|
2022-11-19 07:08:11 +09:00
|
|
|
|
2023-10-13 23:23:17 +09:00
|
|
|
<link rel="resource" type="application/l10n" href="../build/generic/web/locale/locale.json">
|
2011-10-11 05:46:43 +09:00
|
|
|
</head>
|
|
|
|
|
<body>
|
2015-05-15 21:02:56 +09:00
|
|
|
<p>Inflight requests: <span id="inflight"></span></p>
|
2015-05-16 02:58:34 +09:00
|
|
|
<p>
|
|
|
|
|
<input type="checkbox" id="disableScrolling">
|
|
|
|
|
<label for="disableScrolling">Disable automatic scrolling</label>
|
|
|
|
|
</p>
|
|
|
|
|
<pre id="output" style="max-height: 800px; overflow-y: scroll;"></pre>
|
2015-05-15 21:02:56 +09:00
|
|
|
<div id="end"></div>
|
2011-10-11 05:46:43 +09:00
|
|
|
</body>
|
2022-12-03 19:54:56 +09:00
|
|
|
<script type="module">
|
|
|
|
|
import { Driver } from "./driver.js";
|
|
|
|
|
|
|
|
|
|
const driver = new Driver({
|
2017-05-31 00:28:50 +09:00
|
|
|
disableScrolling: document.getElementById('disableScrolling'),
|
|
|
|
|
inflight: document.getElementById('inflight'),
|
|
|
|
|
output: document.getElementById('output'),
|
|
|
|
|
end: document.getElementById('end')
|
2015-05-15 22:29:43 +09:00
|
|
|
});
|
2017-05-31 00:28:50 +09:00
|
|
|
driver.run();
|
2015-05-15 21:02:56 +09:00
|
|
|
</script>
|
Initial import of first test harness
The harness (test.py) operates as follows. First it locates executable browsers
(or symlinks or scripts) named "[browser][version]", e.g. "firefox4".
It then launches the located browsers and asks them to load the file
test_slave.html. At the same time, test.py sets up an HTTP server on
localhost:8080 (there's a race condition here currently ;). After
test_slave loads in the browser(s), it fetches the task manifest
(test_manifest.json). The entries in the manifest specify which PDF
to load and how many times to cycle through page rendering. This will
probably evolve over time. test_slave then performs the requested
tasks and POSTs the results back to test.py, which saves them. When
all the results of for a task are in, test.py checks them.
There are three types of tests currently. "==" tests compare the
rendering of a PDF against a master copy. This is not yet implemented
because setting up a master copy is complicated. "fbf" tests render
all a PDF's pages, then go back to page 1 and render all pages a
second time. The renderings from the first round must match the ones
from the second round. "load" tests just check that a PDF's pages
load without errors.
Currently the test harness will only launch a "firefox4" target. This
can be a bash script in your pdf.js checkout, pdf.js/firefox4,
something like the following
#!/bin/bash
dist="/path/to/firefox4/installation"
profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'`
$dist/firefox -no-remote -profile $profile $*
rm -rf $profile
(Yes, this script doesn't clean up properly on early termination.)
It's possible to run the tests in a normal browsing session, but that
might be annoying. With that set up, run the harness like so
python test.py
If all goes well, you'll see all "TEST-PASS" messages printed to
stdout. If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL"
printed to stdout.
2011-06-19 10:09:21 +09:00
|
|
|
</html>
|
