Change how src/shared/compatibility.js is imported
#15510
Conversation
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/7d5a4415229546b/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/7d5a4415229546b/output.txt Total script time: 2.13 mins Published |
|
/botio test |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/e5559316970ad4e/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/bfb56dda5990f52/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/bfb56dda5990f52/output.txt Total script time: 26.98 mins
Image differences available at: http://54.241.84.105:8877/bfb56dda5990f52/reftest-analyzer.html#web=eq.log |
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/e5559316970ad4e/output.txt Total script time: 29.36 mins
|
Snuffleupagus
changed the title
src/shared/compatibility.js is importedsrc/shared/compatibility.js is imported
Snuffleupagus
force-pushed
the
compatibility-loading
branch
from
04a398d
to
13cf862
Compare
|
Looks good once the conflict is resolved; thank you! |
Currently the compatibility-file is loaded using a standard `import`-statement and while its code is enclosed in a pre-processor block, and thus is excluded in e.g. the MOZCENTRAL build-target, it still results in the *built* `pdf.js`/`pdf.worker.js` files having an effectively empty closure as a result. By moving the checks from `src/shared/compatibility.js` and into `src/shared/util.js` instead, we can load the file using a build-time `require`-statement and thus avoid that closure. Note that with these changes the compatibility-file will no longer be loaded in development mode, i.e. when `gulp server` is used. However, this shouldn't be a big issue given that none of its included polyfills could be loaded then anyway (since `require`-statements are being used) and that it's really only intended for the `legacy`-builds of the library.
Snuffleupagus
force-pushed
the
compatibility-loading
branch
from
13cf862
to
3e62599
Compare
|
/botio unittest |
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/45a97f6e51f9233/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/75e515e6aad475d/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/45a97f6e51f9233/output.txt Total script time: 3.05 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.193.163.58:8877/75e515e6aad475d/output.txt Total script time: 8.37 mins
|
Currently the compatibility-file is loaded using a standard
import-statement and while its code is enclosed in a pre-processor block, and thus is excluded in e.g. the MOZCENTRAL build-target, it still results in the builtpdf.js/pdf.worker.jsfiles having an effectively empty closure as a result. By moving the checks fromsrc/shared/compatibility.jsand intosrc/shared/util.jsinstead, we can load the file using a build-timerequire-statement and thus avoid that closure.Note that with these changes the compatibility-file will no longer be loaded in development mode, i.e. when
gulp serveris used. However, this shouldn't be a big issue given that none of its included polyfills could be loaded then anyway (sincerequire-statements are being used) and that it's really only intended for thelegacy-builds of the library.