Commit Graph

438 Commits

Author SHA1 Message Date
Tim van der Meij
efd331daa1
Consistently use string for string data types in JSDoc comments
Sometimes we also used `String`, but `string` is the what the JSDoc
documentation recommends.
2019-10-13 13:58:17 +02:00
Jonas Jenwald
03387ebaa8 Update src/shared/compatibility.js to only run with SKIP_BABEL = false set
Rather than specifying certain build targets manually, it seems much more appropriate (and future-proof) to use the `SKIP_BABEL` build target instead.

Also, the patch adds a missing `/* eslint no-var: error */` line since I'm touch the file anyway and no code-changes were necessary for it.
2019-10-13 11:33:41 +02:00
Jonas Jenwald
eabedab38e [MessageHandler] Add a non-PRODUCTION/TESTING check to ensure that wrapReason is called with a valid reason
There shouldn't be any situation where `reason` isn't either an `Error`, or a cloned "Error" sent via `postMessage`.
2019-10-06 14:15:13 +02:00
Jonas Jenwald
9201c8dad4 [MessageHandler] Convert the deleteStreamController helper function to a "private" method instead 2019-10-06 14:15:02 +02:00
Jonas Jenwald
5d93fda4f2 Convert the various ...Exceptions to proper classes, to reduce code duplication
By utilizing a base "class", things become significantly simpler. Unfortunately the new `BaseException` cannot be a proper ES6 class and just extend `Error`, since the SystemJS dependency doesn't seem to play well with that.
Note also that we (generally) need to keep the `name` property on the actual `...Exception` object, rather than on its prototype, since the property will otherwise be dropped during the structured cloning used with `postMessage`.
2019-09-29 10:16:20 +02:00
Jonas Jenwald
0ee373f9cc Replace the bundled ReadableStream polyfill with the web-streams-polyfill npm package (issue 11157)
Compared to the recently replaced `URL` polyfill, the new `ReadableStream` polyfill isn't being exported globally for two reasons:
 - We're currently checking for the existence of a global `ReadableStream` implementation when determining if the Fetch API will be used; please see `isFetchSupported` in the src/display/display_utils.js file.
 - Given that it's much newer functionality (compared to `URL`) and that not all browsers may implement all parts of the specification yet, not exposing the `ReadableStream` globally seems safer for now.
2019-09-23 22:16:59 +02:00
Tim van der Meij
1f5ebfbf0c
Replace our URL polyfill with the one from core-js
`core-js` polyfills have proven to be of good quality and using them
prevents us from having to maintain them ourselves.
2019-09-19 14:09:51 +02:00
Tim van der Meij
c71a291317
Upgrade core-js to version 3.2.1
This only required changing the import paths. The `es` folder contains
all polyfills we need now. If we want to import everything, we need to
explicitly require the `index` file.
2019-09-19 13:58:36 +02:00
Jonas Jenwald
4bd79ec4b3 Inline the resolveOrReject helper function at its call-sites in MessageHandler, and rename an error key to reason
Given that there's only a couple of call-sites, and that the helper function is really simple, it doesn't seem entirely necessary to keep it around. While fewer function calls is always a good thing, in this case the performance impact is small enough to be unmeasurable.

With *one* single exception the code in `MessageHandler` is using `reason` when passing around various Errors, hence this patch also renames an `error` key for consistency.
2019-09-17 14:22:24 +02:00
Jonas Jenwald
0617984b59 Remove unnecessary data.streamId accesses in MessageHandler._processStreamMessage, and use a constant object shape in MessageHandler.sendWithStream
The `streamId` short-hand in `MessageHandler._processStreamMessage` was only used partially througout the method, which seemed kind of strange, hence that's fixed in this patch.
Furthermore, always giving the `streamController` object a constant shape in `MessageHandler.sendWithStream` cannot hurt either.
2019-09-17 14:18:57 +02:00
Jonas Jenwald
74f5a59f43 Ensure that the cancel/error methods on Streams are always called with valid reason arguments 2019-09-02 23:31:07 +02:00
Jonas Jenwald
02bdacef42 Ensure that Errors are handled correctly when using postMessage with Streams in MessageHandler
Having recently worked with this code, it struck me that most of the `postMessage` calls where `Error`s are involved have never been correctly implemented (i.e. missing `wrapReason` calls).
2019-09-02 23:31:07 +02:00
Jonas Jenwald
cd82b81bc7 Inline the resolveCall helper function at its call-sites in MessageHandler
There's only three call-sites and one of them doesn't even need the complete functionality of `resolveCall`, hence it seems reasonable to just inline this code.
An additional benefit of this is that the `Function.prototype.apply()` instance can also be converted into "normal" function calls, which should be a tiny bit more efficient.

The patch also replaces a number of unnecessary arrow functions, in relevant parts of the `MessageHandler` code, with "normal" functions instead.
Finally, all `Promise.resolve().then(...)` calls are replaced with `new Promise(...)` instead since the latter is a tiny bit more efficient. This also explains the test failures on the Linux bot, with a prior version of the patch, since the `Promise.resolve().then(...)` format essentially creates two Promises thus causing additional delay.
2019-09-01 13:40:19 +02:00
Jonas Jenwald
055f03938b Remove support for the scope parameter in the MessageHandler.on method
At this point in time it's easy to convert the `MessageHandler.on` call-sites to use arrow functions, and thus let the JavaScript engine handle scopes for us, rather than having to manually keep references to the relevant scopes in `MessageHandler`.[1]
An additional benefit of this is that a couple of `Function.prototype.call()` instances can now be converted into "normal" function calls, which should be a tiny bit more efficient.

All in all, I don't see any compelling reason why it'd be necessary to keep supporting custom `scope`s in the `MessageHandler` implementation.

---
[1] In the event that a custom scope is ever needed, simply using `bind` on the handler function when calling `MessageHandler.on` ought to work as well.
2019-09-01 09:24:15 +02:00
Jonas Jenwald
f71ea2de0e Remove the makeReasonSerializable helper function, and use wrapReason instead, in src/shared/message_handler.js
Since `wrapReason` and `makeReasonSerializable` are essentially functionally equivalent it doesn't seem necessary to keep both of them around, especially when `makeReasonSerializable` only has a *single* call-site.
2019-08-30 19:36:10 +02:00
Jonas Jenwald
4e6a9b54c7 Change the internal stream property, as sent when Streams are used, from a String to a Number
Given that the `stream` property is an internal implementation detail, changing its type shouldn't be a problem. By using Numbers instead, we can avoid unnecessary String allocations when creating/processing Streams.
2019-08-30 13:27:18 +02:00
Jonas Jenwald
252a3e35fb Reduce the amount of unnecessary function calls and object allocations, in MessageHandler, when using Streams
With PR 11069 we're now using Streams for OperatorList parsing (in addition to just TextContent parsing), which brings the nice benefit of being able to easily abort parsing on the worker-thread thus saving resources.

However, since we're now creating many more `ReadableStream` there appears to be a tiny bit more overhead because of it (giving ~1% slower runtime of `browsertest` on the bots). In this case we're just going to have to accept such a small regression, since the benefits of using Streams clearly outweighs it.

What we *can* do here, is to try and make the Streams part of the `MessageHandler` implementation slightly more efficient by e.g. removing unnecessary function calls (which has been helpful in other parts of the code-base). To that end, this patch makes the following changes:

 - Actually support `transfers` in `MessageHandler.sendWithStream`, since the parameter was being ignored.

 - Inline the `sendStreamRequest`/`sendStreamResponse` helper functions at their respective call-sites. Obviously this causes some amount of code duplication, however I still think this change seems reasonable since for each call-site:
   - It avoids making one unnecessary function call.
   - It avoids allocating one temporary object.
   - It avoids sending, and thus structure clone, various undefined object properties.

 - Inline objects in the `MessageHandler.{send, sendWithPromise}` methods.

 - Finally, directly call `comObj.postMessage` in various methods when `transfers` are *not* present, rather than calling `MessageHandler.postMessage`, to further reduce the amount of function calls.
2019-08-30 12:32:20 +02:00
Brendan Dahl
c8129b8787 Move polyfill for codePointAt to String prototype.
This method belongs on the prototype not the String object.
2019-08-16 14:32:43 -07:00
Jonas Jenwald
7f456b3e2e Replace of all usages of var with let/const in the src/shared/util.js file
Also removes a couple of unnecessary (temporary) variable assigments in `arraysToBytes` and uses template strings in a few spots.
2019-08-11 14:35:35 +02:00
Jonas Jenwald
f6c4a1f080 Convert Util to a class with static methods
Also replaces `var` with `const` in all the relevant code.
2019-08-11 14:35:35 +02:00
Jonas Jenwald
7ee370a394 Remove the skipEmpty parameter from Util.intersect (PR 11059 follow-up)
Looking at this again, it struck me that added functionality in `Util.intersect` is probably more confusing than helpful in general; sorry about the churn in this code!
Based on the parameter name you'd probably expect it to only match when the intersection is `[0, 0,  0, 0]` and not when only one component is zero, hence the `skipEmpty` parameter thus feels too tightly coupled to the `Page.view` getter.
2019-08-11 14:33:52 +02:00
Jonas Jenwald
d637b25e36 Fallback gracefully when encountering corrupt PDF files with empty /MediaBox and /CropBox entries
This is based on a real-world PDF file I encountered very recently[1], although I'm currently unable to recall where I saw it.
Note that different PDF viewers handle these sort of errors differently, with Adobe Reader outright failing to render the attached PDF file whereas PDFium mostly handles it "correctly".

The patch makes the following notable changes:
 - Refactor the `cropBox` and `mediaBox` getters, on the `Page`, to reduce unnecessary duplication. (This will also help in the future, if support for extracting additional page bounding boxes are added to the API.)
 - Ensure that the page bounding boxes, i.e. `cropBox` and `mediaBox`, are never empty to prevent issues/weirdness in the viewer.
 - Ensure that the `view` getter on the `Page` will never return an empty intersection of the `cropBox` and `mediaBox`.
 - Add an *optional* parameter to `Util.intersect`, to allow checking that the computed intersection isn't actually empty.
 - Change `Util.intersect` to have consistent return types, since Arrays are of type `Object` and falling back to returning a `Boolean` thus seem strange.

---

[1] In that case I believe that only the `cropBox` was empty, but it seemed like a good idea to attempt to fix a bunch of related cases all at once.
2019-08-09 10:18:13 +02:00
Brendan Dahl
31d71808e7 [api-minor] Update telemetry to use 'categorical' histograms.
Firefox telemetry supports using string labels now. Convert our integers
that we used for categories to just use strings.

The upstream work will happen in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1566882
2019-08-01 09:51:02 -07:00
vlastimilmaca
fe49f0f766 Annotations - Implement parsing of IRT, RT, State and StateModel 2019-07-16 23:33:07 +02:00
Jonas Jenwald
b548bafef7 Simplify, and inline, the finalize function in the MessageHandler class
The `finalize` helper function has only a *single* call-site, and furthermore it's just a one-liner too. Furthermore it's only ever called with a `Promise` as its argument, meaning that it's unnecessarily convoluted as well (i.e. the `Promise.resolve()` part shouldn't be necessary).
Hence this code can be both simplified *and* inlined at its only call-site instead.
2019-07-13 17:54:32 +02:00
Jonas Jenwald
17116917f7 Remove useless wrapReason calls in the MessageHandler class
Currently `wrapReason` is manually called at *every* `resolveOrReject` call-site, despite it being completely unnecessary unless there's an actual error being handled. This is obviously inefficient, and it's easy enough to avoid by having `resolveOrReject` handle this only when actually needed.
2019-07-13 13:08:29 +02:00
Jonas Jenwald
173fbef05b Enable the consistent-return ESLint rule
This rule is already enabled in mozilla-central, and helps ensure more consistent functions/methods, see https://searchfox.org/mozilla-central/rev/b9da45f63cb567244933c77b2c7e827a057d3f9b/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#119-120

Please see https://eslint.org/docs/rules/consistent-return for additional information.
2019-05-11 14:27:21 +02:00
wuhao.daraw
1472c10bab fix: electron enviroment detection 2019-03-26 20:52:49 +08:00
Jonas Jenwald
88f9e633dd Try to improve text-selection for Type3 fonts that utilize a non-default /FontMatrix (bug 1513120)
For Type3 fonts text-selection is often not that great, and there's a couple of heuristics used to try and improve things. This patch simple extends those heuristics a bit, and fixes a pre-existing "naive" array comparison, but this all feels a bit brittle to say the least.

The existing Type3 test-coverage isn't that great in general, and in particular Type3 `text` tests are few and far between, hence why this patch adds *two* different new `text` tests.
2019-03-12 10:32:08 +01:00
Jonas Jenwald
7caf769a66 Move the deprecated helper function to the src/display/display_utils.js file
Given that the function is (purposely) independent of the verbosity level and that its message is worded to only apply on the main-thread, there's no reason to duplicate this across the built `pdf.js`/`pdf.worker.js` files.
2019-03-02 20:23:56 +01:00
Jonas Jenwald
db5dc14158 Move worker-thread only functions from src/shared/util.js and into a new src/core/core_utils.js file
The `src/shared/util.js` file is being bundled into both the `pdf.js` and `pdf.worker.js` files, meaning that its code is by definition duplicated.
Some main-thread only utility functions have already been moved to a separate `src/display/display_utils.js` file, and this patch simply extends that concept to utility functions which are used *only* on the worker-thread.

Note in particular the `getInheritableProperty` function, which expects a `Dict` as input and thus *cannot* possibly ever be used on the main-thread.
2019-02-24 00:35:39 +01:00
Jonas Jenwald
b6d090cc14 Fallback to the built-in font renderer when font loading fails
After PR 9340 all glyphs are now re-mapped to a Private Use Area (PUA) which means that if a font fails to load, for whatever reason[1], all glyphs in the font will now render as Unicode glyph outlines.
This obviously doesn't look good, to say the least, and might be seen as a "regression" since previously many glyphs were left in their original positions which provided a slightly better fallback[2].

Hence this patch, which implements a *general* fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). One caveat here is that this only works for the Font Loading API, since it's easy to handle errors in that case[3].

The solution implemented in this patch does *not* in any way delay the loading of valid fonts, which was the problem with my previous attempt at a solution, and will only require a bit of extra work/waiting for those fonts that actually fail to load.

*Please note:* This patch doesn't fix any of the underlying PDF.js font conversion bugs that's responsible for creating corrupt font files, however it does *improve* rendering in a number of cases; refer to this possibly incomplete list:

[Bug 1524888](https://bugzilla.mozilla.org/show_bug.cgi?id=1524888)
Issue 10175
Issue 10232

---
[1] Usually because the PDF.js font conversion code wasn't able to parse the font file correctly.

[2] Glyphs fell back to some default font, which while not accurate was more useful than the current state.

[3] Furthermore I'm not sure how to implement this generally, assuming that's even possible, and don't really have time/interest to look into it either.
2019-02-11 10:27:08 +01:00
Jonas Jenwald
3bcf9187ec Add a polyfill for classList.{add, remove} with more than one parameter
Unsurprisingly IE11 doesn't support this, so a polyfill is needed since otherwise the sidebar can no longer be opened.

Also, simplifies the existing `classList.toggle` polyfill.
2019-02-08 13:35:01 +01:00
Jonas Jenwald
614e502227 [api-minor] Remove the document.currentScript polyfill
This polyfill is currently used in only *one* file, i.e. `src/display/api.js`, and only when trying to build a *fallback* `workerSrc` path.

Given that the global `workerSrc` should *always* be set[1] when using the PDF.js library[2], and that the fallback `workerSrc` should only be regarded as a best-effort solution anyway, there isn't a particularily strong reason to keep the compatibility code in my opinion.

---
[1] Other supported options include setting the global `workerPort`, or passing in a `PDFWorker` instance as part of the `getDocument` call.

[2] Which is clearly mentioned in the JSDocs in `src/display/worker_options.js`.
2019-02-03 14:09:24 +01:00
Jonas Jenwald
22468817e1 Add a settled property, tracking the fulfilled/rejected stated of the Promise, to createPromiseCapability
This allows cleaning-up code which is currently manually tracking the state of the Promise of a `createPromiseCapability` instance.
2019-02-02 15:18:56 +01:00
Jonas Jenwald
249b199ff1 Stop bundling the ReadableStream polyfill in MOZCENTRAL builds (PR 10470 follow-up)
Based on the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1521413, this patch simply removes the `ReadableStream` polyfill completely from MOZCENTRAL builds.

With this patch, the size of the `gulp mozcentral` build target is thus further reduced (building on PR 10470):

|       | `build/mozcentral`
|-------|-------------------
|master |   3 339 666
|patch  |   3 209 572
2019-01-23 20:33:20 +01:00
Jonas Jenwald
01d624f6a0 Add an Array.from polyfill, using core-js, and remove some compatibility hacks from the src/display/content_disposition.js file 2019-01-20 08:49:20 +01:00
Tim van der Meij
66acc7397f
Merge pull request #10470 from Snuffleupagus/mozcentral-streams
Try to, completely, avoid loading the `ReadableStream` polyfill in MOZCENTRAL builds
2019-01-19 21:22:18 +01:00
Jonas Jenwald
480110625a Try to, completely, avoid loading the ReadableStream polyfill in MOZCENTRAL builds
With https://bugzilla.mozilla.org/show_bug.cgi?id=1505122 landing in Firefox 65, the native `ReadableStream` implementation is now enabled by default in Firefox.

Obviously it would be nice to simply stop bundling the polyfill in MOZCENTRAL builds altogether, however given that it's still possible to disable[1] `ReadableStream` this is probably not a good idea just yet.
Nonetheless, now that native support is available, it seems unnecessary (and wasteful) to keep bundling the polyfill twice[2] in MOZCENTRAL builds. Hence this patch, which contains a suggest approach for packing the polyfill in a *separate* file which is then *only* loaded if/when needed.

With this patch, the size of the `gulp mozcentral` build target is thus reduced accordingly:

|       | `build/mozcentral`
|-------|-------------------
|master |   3 461 089
|patch  |   3 340 268

Besides the PDF.js files taking up less space in Firefox this way, the additional benefit is that there's (by default) less code that needs to be loaded and parsed when the PDF Viewer is used which also cannot hurt.

---
[1] In `about:config`, by toggling the `javascript.options.streams` preference.

[2] Once in the `build/pdf.js` file, and once in the `build/pdf.worker.js` file.
2019-01-19 09:05:01 +01:00
Jonas Jenwald
24a688d6c6 Convert some usage of indexOf to startsWith/includes where applicable
In many cases in the code you don't actually care about the index itself, but rather just want to know if something exists in a String/Array or if a String starts in a particular way. With modern JavaScript functionality, it's thus possible to remove a number of existing `indexOf` cases.
2019-01-18 17:57:41 +01:00
Jonas Jenwald
68ad3e8e9d Tweak the DOMTokenList.toggle polyfill (issue 10460) 2019-01-16 20:15:44 +01:00
Jonas Jenwald
358cd0c096 Add a few more String polyfills (startsWith, endsWith, padStart, padEnd) 2019-01-06 20:10:55 +01:00
Jonas Jenwald
60bcce184e Check that the first page can be successfully loaded, to try and ascertain the validity of the XRef table (issue 7496, issue 10326)
For PDF documents with sufficiently broken XRef tables, it's usually quite obvious when you need to fallback to indexing the entire file. However, for certain kinds of corrupted PDF documents the XRef table will, for all intents and purposes, appear to be valid. It's not until you actually try to fetch various objects that things will start to break, which is the case in the referenced issues[1].

Since there's generally a real effort being in made PDF.js to load even corrupt PDF documents, this patch contains a suggested approach to attempt to do a bit more validation of the XRef table during the initial document loading phase.

Here the choice is made to attempt to load the *first* page, as a basic sanity check of the validity of the XRef table. Please note that attempting to load a more-or-less arbitrarily chosen object without any context of what it's supposed to be isn't a very useful, which is why this particular choice was made.
Obviously, just because the first page can be loaded successfully that doesn't guarantee that the *entire* XRef table is valid, however if even the first page fails to load you can be reasonably sure that the document is *not* valid[2].

Even though this patch won't cause any significant increase in the amount of parsing required during initial loading of the document[3], it will require loading of more data upfront which thus delays the initial `getDocument` call.
Whether or not this is a problem depends very much on what you actually measure, please consider the following examples:

```javascript
console.time('first');
getDocument(...).promise.then((pdfDocument) => {
  console.timeEnd('first');
});

console.time('second');
getDocument(...).promise.then((pdfDocument) => {
  pdfDocument.getPage(1).then((pdfPage) => { // Note: the API uses `pageNumber >= 1`, the Worker uses `pageIndex >= 0`.
    console.timeEnd('second');
  });
});
```

The first case is pretty much guaranteed to show a small regression, however the second case won't be affected at all since the Worker caches the result of `getPage` calls. Again, please remember that the second case is what matters for the standard PDF.js use-case which is why I'm hoping that this patch is deemed acceptable.

---
[1] In issue 7496, the problem is that the document is edited without the XRef table being correctly updated.
In issue 10326, the generator was sorting the XRef table according to the offsets rather than the objects.

[2] The idea of checking the first page in particular came from the "standard" use-case for the PDF.js library, i.e. the default viewer, where a failure to load the first page basically means that nothing will work; note how `{BaseViewer, PDFThumbnailViewer}.setDocument` depends completely on being able to fetch the *first* page.

[3] The only extra parsing is caused by, potentially, having to traverse *part* of the `Pages` tree to find the first page.
2018-12-29 12:47:25 +01:00
Romain Petit
13b0ca6b2a Don't detect nw.js as node.js
nw.js is chrome plus nodejs.
It will succeed everywhere chrome succeeds, but fail in many cases where nodejs succeeds (see issue 9071).
So it's safer to consider it as a browser context rather than a nodejs context.

Make travis happy again

CS

Readability + Explanation

The relevant portion of the NW.js documentation:
http://docs.nwjs.io/en/latest/For%20Users/Advanced/JavaScript%20Contexts%20in%20NW.js/#access-nodejs-and-nwjs-api-in-browser-context

Added full link to relevant doc.
2018-11-07 11:14:22 +01:00
Jonas Jenwald
f23dba1c10 Change canvasInRendering to a WeakSet instead of a WeakMap
Note how nowhere in the code `canvasInRendering.get()` is ever called, and that this structure is really only used to store references to `<canvas>` DOM elements.
The reason for this being a `WeakMap` is probably because at the time we weren't using `core-js` polyfills yet, and since there already existed a manually implemented `WeakMap` polyfill it was probably simpler to use that.
2018-10-31 18:15:23 +01:00
Jonas Jenwald
4cde844ffe Add a DOMTokenList.toggle polyfill for the second, optional, "force" parameter
This is based on the polyfill available at https://developer.mozilla.org/en-US/docs/Web/API/Element/classList#Polyfill
2018-10-12 15:41:09 +02:00
Jonas Jenwald
d6f4d2ff33 Add a Symbol polyfill, using core-js, to allow using for...of loops
https://github.com/zloirock/core-js#ecmascript-symbol
2018-09-29 16:05:00 +02:00
Tim van der Meij
bf13c8a50b
Use the const keyword for constants in src/shared/util.js
Moreover, move general constants to the top of the file, i.e., those
that are not closely tied to a function in the file.
2018-09-11 16:17:45 +02:00
Tim van der Meij
99de25d6cc
Implement unit tests for the isSameOrigin and createValidAbsoluteUrl utility functions
Moreover, mark the `isValidProtocol` function as private since it's only
used in the utilities file and is not (meant to be) exported.
2018-09-11 16:17:45 +02:00
Tim van der Meij
66422eb83e
Merge pull request #9340 from brendandahl/private-use
Map all glyphs to the private use area and duplicate the first glyph.
2018-09-08 17:51:04 +02:00
Brendan Dahl
b76cf665ec Map all glyphs to the private use area and duplicate the first glyph.
There have been lots of problems with trying to map glyphs to their unicode
values. It's more reliable to just use the private use areas so the browser's
font renderer doesn't mess with the glyphs.

Using the private use area for all glyphs did highlight other issues that this
patch also had to fix:

  * small private use area - Previously, only the BMP private use area was used
    which can't map many glyphs. Now, the (much bigger) PUP 16 area can also be
    used.

  * glyph zero not shown - Browsers will not use the glyph from a font if it is
    glyph id = 0. This issue was less prevalent when we mapped to unicode values
    since the fallback font would be used. However, when using the private use
    area, the glyph would not be drawn at all. This is illustrated in one of the
    current test cases (issue #8234) where there's an "ä" glyph at position
    zero. The PDF looked like it rendered correctly, but it was actually not
    using the glyph from the font. To properly show the first glyph it is always
    duplicated and appended to the glyphs and the maps are adjusted.

  * supplementary characters - The private use area PUP 16 is 4 bytes, so
    String.fromCodePoint must be used where we previously used
    String.fromCharCode. This is actually an issue that should have been fixed
    regardless of this patch.

  * charset - Freetype fails to load fonts when the charset size doesn't match
    number of glyphs in the font. We now write out a fake charset with the
    correct length. This also brought up the issue that glyphs with seac/endchar
    should only ever write a standard charset, but we now write a custom one.
    To get around this the seac analysis is permanently enabled so those glyphs
    are instead always drawn as two glyphs.
2018-09-05 14:04:54 -07:00
Tim van der Meij
959ed3705b
Implement a permissions API 2018-09-02 21:23:09 +02:00
Jonas Jenwald
099ed08852 Add support for async/await using Babel
For proof-of-concept, this patch converts a couple of `Promise` returning methods to use `async` instead.
Please note that the `generic` build, based on this patch, has been successfully testing in IE11 (i.e. the viewer loads and nothing is obviously broken).

Being able to use modern JavaScript features like `async`/`await` is a huge plus, but there's one (obvious) side-effect: The size of the built files will increase slightly (unless `SKIP_BABEL == true`). That's unavoidable, but seems like a small price to pay in the grand scheme of things.

Finally, note that the `chromium` build target was changed to no longer skip Babel translation, since the Chrome extension still supports version `49` of the browser (where native `async` support isn't available).
2018-08-19 16:54:11 +02:00
Jonas Jenwald
50a47be190 [api-minor] Remove the obsolete createBlob helper function
At this point in time, all supported browsers have native support for `Blob`; please see https://developer.mozilla.org/en-US/docs/Web/API/Blob/Blob#Browser_compatibility.
Furthermore, note how the helper function was throwing an error if `Blob` isn't available anyway.
2018-08-19 13:37:19 +02:00
Jonas Jenwald
8e76d26e5b Move the toRoman helper function out of the Util scope
Compared to all the other (static) methods in `Util`, the `toRoman` one looks slightly out of place. Even more so considering that `Util` is being exposed through `pdfjsLib`, where access to a Roman numerals conversion method doesn't make much sense.
2018-07-10 10:45:25 +02:00
Jonas Jenwald
c1c49badff Remove the, now unused, Util.inherit helper function 2018-07-10 10:29:47 +02:00
Tim van der Meij
646d81cd09
Merge pull request #9837 from timvandermeij/unreachable
Replace `NotImplementedException` with `unreachable`
2018-07-09 21:10:36 +02:00
Jonas Jenwald
a9ce4e8417 Stop exposing the URL polyfill in the global scope
This moves/exposes the `URL` polyfill similarily to the existing `ReadableStream` polyfill, rather than exposing it globally, to avoid interfering with any "outside" code.
Both the `URL` and `ReadableStream` polyfills are now exposed on the `pdfjsLib` object, such that they are accessible to the viewer components.
Furthermore, the `no-restricted-globals` ESLint rule is also enabled to prevent accidental usage of the native `URL`/`ReadableStream` implementations directly in the `src/` and `web/` folders; see also https://eslint.org/docs/rules/no-restricted-globals

Addresses the remaining TODO in https://github.com/mozilla/pdf.js/projects/6
2018-07-04 09:16:28 +02:00
Tim van der Meij
14b69a4c1c
Merge pull request #9729 from Snuffleupagus/gulp-image_decoders
Add a `gulp image_decoders` command to package the image decoders (i.e. jpg.js, jpx.js, jbig2.js) separately, and publish them in pdfjs-dist
2018-06-26 23:27:32 +02:00
Tim van der Meij
2907827d31
Replace NotImplementedException with unreachable 2018-06-23 21:20:53 +02:00
Jonas Jenwald
303537bcb1 Add a gulp image_decoders command to allow packaging/distributing the image decoders (i.e. jpg.js, jpx.js, jbig2.js) separately from the main PDF.js library
Please note that the standalone `pdf.image_decoders.js` file will be including the complete `src/shared/util.js` file, despite only using parts of it.[1] This was done *purposely*, to not negatively impact the readability/maintainability of the core PDF.js code.

Furthermore, to ensure that the compatibility is the same in the regular PDF.js library *and* in the the standalone image decoders, `src/shared/compatibility.js` was included as well.

To (hopefully) prevent future complaints about the size of the built `pdf.image_decoders.js` file, a few existing async-related polyfills are being skipped (since all of the image decoders are completely synchronous).
Obviously this required adding a couple of pre-processor statements, but given that these are all limited to "compatibility" code, I think this might be OK!?

---
[1] However, please note that previous commits moved `PageViewport` and `MessageHandler` out of `src/shared/util.js` which reduced its size.
2018-06-16 17:56:54 +02:00
Tim van der Meij
af8e88d00b
Replace Util.extendObj by Object.assign 2018-06-10 20:11:03 +02:00
Tim van der Meij
903bad1906
Remove Util.appendToArray and Util.prependToArray
The former may be replaced by regular JavaScript array concatenation and
the latter is unused. This avoids unnecessary function calls/imports.
2018-06-10 15:24:09 +02:00
Jonas Jenwald
07d610615c Move, and modernize, Util.loadScript from src/shared/util.js to src/display/dom_utils.js
Not only is the `Util.loadScript` helper function unused on the Worker side, even trying to use it there would throw an Error (since `document` isn't defined/available in Workers).
Hence this helper function is moved, and its code modernized slightly by having it return a Promise rather than needing a callback function.

Finally, to reduced code duplication, the "new" loadScript function is exported and used in the viewer.
2018-06-07 13:52:40 +02:00
Jonas Jenwald
44d8afd46b Move MessageHandler into a separate src/shared/message_handler.js file
The `MessageHandler` itself, and its assorted helper functions, are currently the single largest[1] piece of code in the `src/shared/util.js` file. By moving this code into its own file, `src/shared/util.js` thus becomes smaller and more manageable.
2018-06-04 12:53:08 +02:00
Jonas Jenwald
08c8f8733d Move PageViewport from src/shared/util.js to src/display/dom_utils.js
Since the `PageViewport` is not used in the worker, duplicating this code on both the main and worker sides seems completely unnecessary.
2018-06-04 12:53:07 +02:00
Tim van der Meij
f308d73d40
Implement a single getInheritableProperty utility function
This function combines the logic of two separate methods into one.
The loop limit is also a good thing to have for the calls in
`src/core/annotation.js`.

Moreover, since this is important functionality, a set of unit tests and
documentation is added.
2018-03-03 19:19:39 +01:00
Jonas Jenwald
b8606abbc1 [api-major] Completely remove the global PDFJS object 2018-03-01 18:13:27 +01:00
Jonas Jenwald
5894bfa449 Move API specific compatibility options from src/shared/compatibility.js and into a separate file
Unfortunately, as far as I can tell, we still need the ability to adjust certain API options depending on the browser environment in PDF.js version `2.0`. However, we should be able to separate this from the general compatibility code in the `src/shared/compatibility.js` file.
2018-03-01 18:11:16 +01:00
Jonas Jenwald
cd12a177a9 Attempt to fix the Array.prototype.includes and String.prototype.includes polyfills (issue 9514, 9516)
I don't understand why the previous way importing the polyfills didn't work, and I don't have time to try and figure it out, however this patch seems to fix things.

Fixes 9514.
Fixes 9516.
2018-03-01 17:38:14 +01:00
Jonas Jenwald
a97901efb6 Move the verbosity option from the global PDFJS object and into getDocument/PDFWorker instead
Given the purpose of this option, it doesn't seem necessary to make it available through `GlobalWorkerOptions`.
2018-02-16 13:22:35 +01:00
Jonas Jenwald
9e0a31f662 Move viewer specific compatibility options from src/shared/compatibility.js and into a separate file
Unfortunately, as far as I can tell, we still need the ability to adjust certain viewer options depending on the browser environment in PDF.js version `2.0`. However, we should be able to separate this from the general compatibility code in the `src/shared/compatibility.js` file.
2018-02-13 13:41:59 +01:00
Jonas Jenwald
1cf116ab88 Enable the mozilla/use-includes-instead-of-indexOf ESLint rule globally
This rule is available from https://www.npmjs.com/package/eslint-plugin-mozilla, and is enforced in mozilla-central. Note that we have the necessary `Array`/`String` polyfills and that most cases have already been fixed, see PRs 9032 and 9434.
2018-02-10 23:24:50 +01:00
Jonas Jenwald
2eb29409bc Enable the mozilla/avoid-removeChild ESLint rule globally
This rule is available from https://www.npmjs.com/package/eslint-plugin-mozilla, and is enforced in mozilla-central. Note that we have a polyfill for `ChildNode.remove()` and that most cases have already been fixed, see PRs 8056 and 8138.
2018-02-10 23:24:50 +01:00
Jonas Jenwald
2570717e77 Inline the code in loadJpegStream at the only call-site in src/display/api.js.js`
Since `loadJpegStream` is only used at a *single* spot in the code-base, and given that it's very heavily tailored to the calling code (since it relies on the data structure of `PDFObjects`), this patch simply inlines the code in `src/display/api.js` instead.
2018-02-05 17:01:35 +01:00
Jonas Jenwald
9ac9ef8ef1 Polyfill String.prototype.includes using core-js
See https://github.com/zloirock/core-js#ecmascript-6-string.
2018-02-04 14:31:59 +01:00
Rob Wu
5d1c541702 Enable some polyfills for compat with Chrome 49
Successfully tested with Chrome 49.
2018-01-26 12:31:41 +01:00
Rob Wu
44025a3ec1 Explicitly state intended support in compatibility.js
Add comments with supported browser versions where missing.

Method:
- Use MDN compat tables if available.
- Otherwise test in Chrome (31+) otherwise.
  (the Chrome Web Store does not update older versions of
   Chrome, so probably nobody is interested in even older
   versions, even though there is an existing comment for
   Chrome<29 at `document.currentScript`).
2018-01-26 12:31:41 +01:00
Jonas Jenwald
0e1b5589e7 Restore the btoa/atob polyfills for Node.js
These were removed in PR 9170, since they were unused in the browsers that we'll support in PDF.js version `2.0`.
However looking at the output of Travis, where a subset of the unit-tests are run using Node.js, there's warnings about `btoa` being undefined. This doesn't appear to cause any errors, which probably explains why we didn't notice this before (despite PR 9201).
2018-01-13 01:31:05 +01:00
Jonas Jenwald
9ff3c6f99d Remove the document.readyState polyfill
This is only relevant for browsers that we don't intend to support with PDF.js version `2.0`.
2017-12-19 15:05:19 +01:00
Jonas Jenwald
6af45052c5 Remove the input.type polyfill
This is only relevant for browsers that we don't intend to support with PDF.js version `2.0`.
2017-12-19 15:05:15 +01:00
Jonas Jenwald
cf88b7b212 Remove the ImageData.set polyfill
This is only relevant for browsers that we don't intend to support with PDF.js version `2.0`.
2017-12-19 15:05:14 +01:00
Jonas Jenwald
363e517acf Remove the HTMLElement.dataset polyfill
This is only relevant for browsers that we don't intend to support with PDF.js version `2.0`.
2017-12-19 14:50:18 +01:00
Jonas Jenwald
4880200cd4 Remove the XMLHttpRequest.response polyfill
This is only relevant for browsers that we don't intend to support with PDF.js version `2.0`.
2017-12-19 14:48:43 +01:00
Jonas Jenwald
8266cc18e7 Remove the webkitURL polyfill
This is only relevant for browsers that we don't intend to support with PDF.js version `2.0`.
2017-12-19 14:46:04 +01:00
Tim van der Meij
c35bbd11b0
Use native Math functions in the custom log2 function
It is quite confusing that the custom function is called `log2` while it
actually returns the ceiling value and handles zero and negative values
differently than the native function.

To resolve this, we add a comment that explains these differences and
make the function use the native `Math` functions internally instead of
using our own custom logic. To verify that the function does what we
expect, we add unit tests.

All browsers except for IE support `Math.log2` for quite a long time
already (see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/log2).
For IE, we use the core-js polyfill.

According to the microbenchmark at https://jsperf.com/log2-pdfjs/1,
using the native functions should also be faster, in my testing almost
six times as fast.
2017-12-10 16:35:17 +01:00
Jonas Jenwald
6b1eda3e12 Move StatTimer from src/shared/util.js to src/display/dom_utils.js
Since the `StatTimer` is not used in the worker, duplicating this code on both the main and worker sides seem completely unnecessary.
2017-12-06 13:51:04 +01:00
Jonas Jenwald
cc47ef56ec Remove the onclick polyfill for old versions of Opera
This was only relevant for no obsolete versions Opera, that use the Presto engine. According to https://en.wikipedia.org/wiki/History_of_the_Opera_web_browser#Opera_2013, the last version affected was released in 2013.
2017-11-21 11:02:14 +01:00
Jonas Jenwald
d18b2a8e73 Remove the classList polyfill
This is only relevant for browsers that we don't intend to support with PDF.js version `2.0`.
2017-11-21 11:01:52 +01:00
Jonas Jenwald
4b15e8566b Remove the Function.prototype.bind polyfill
This is only relevant for browsers that we don't intend to support with PDF.js version `2.0`.
2017-11-21 11:00:55 +01:00
Jonas Jenwald
d8cb74d3e3 Remove the btoa/atob polyfills
This is only relevant for browsers that we don't intend to support with PDF.js version `2.0`.
2017-11-21 11:00:55 +01:00
Jonas Jenwald
150ac0788f Remove IE9 specific XMLHttpRequest polyfills that utilize VBArray 2017-11-21 11:00:55 +01:00
Jonas Jenwald
935c5c587f Remove the Object.defineProperty polyfill
This is only relevant for browsers that we don't intend to support with PDF.js version `2.0`.
2017-11-21 11:00:55 +01:00
Jonas Jenwald
42099c564f Remove the console polyfills
All browsers that we intend to support with PDF.js version 2.0 already supports `console` natively.
2017-11-16 09:34:51 +01:00
Jonas Jenwald
d5174cd826 Remove the requestAnimationFrame polyfill
According to https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame#Browser_compatibility and https://caniuse.com/#feat=requestanimationframe, the browsers we intend to support with PDF.js version 2.0 should all have native `requestAnimationFrame` support.

Note that the reason for indiscriminately polyfilling `requestAnimationFrame` in iOS, see PR 4961, was apparently because of a bug in iOS 6.
However, according to [Wikipedia](https://en.wikipedia.org/wiki/IOS_version_history#iOS_8): "Support for iOS 8 ended in 2017.", hence the lowest version currently supported is iOS 9.
2017-11-15 16:08:48 +01:00
Jonas Jenwald
745cb73c65 Remove PDFJS.disableRange/PDFJS.disableStream code for now unsupported browsers in src/shared/compatibility.js
We're currently disabling range requests and streaming for a number of configurations. A couple of those will no longer be supported (with PDF.js version 2.0), hence we ought to be able to clean up the compatibility code slightly.
2017-11-14 15:28:50 +01:00
Jonas Jenwald
eb3a1f24a3 Remove the PDFJS.disableHistory code from src/shared/compatibility.js
This compatibility code is only relevant for browsers that will no longer be supported (with PDF.js version 2.0), hence we ought to be able to remove it.
2017-11-14 15:28:50 +01:00
Jonas Jenwald
2dbd3f2603 [api-major] Remove the TypedArray polyfills 2017-11-01 10:31:28 +01:00
Yury Delendik
b4e25fb2e8 Merge remote-tracking branch 'mozilla/version-2.0' into v2 2017-10-27 14:01:45 -05:00
Tim van der Meij
a0ec980e63 Merge pull request #9055 from Snuffleupagus/core-js-Number
Replace `Number` polyfills with the ones from core-js
2017-10-21 16:15:11 +02:00
Jonas Jenwald
dbbb763eaf Replace Number polyfills with the ones from core-js
Since we're already using core-js elsewhere in `compatibility.js`, we can reduce the amount of code we need to maintain ourselves.

https://github.com/zloirock/core-js#ecmascript-6-number
2017-10-21 12:58:53 +02:00
Jonas Jenwald
8684aa0ee5 Replace our Promise polyfill with the one from core-js
Since we're already using core-js elsewhere in `compatibility.js`, we can reduce the amount of code we need to maintain ourselves.

https://github.com/zloirock/core-js#ecmascript-6-promise
2017-10-21 12:51:14 +02:00
Jonas Jenwald
bcb29063c1 Polyfill Object.values and Array.prototype.includes using core-js
See https://github.com/zloirock/core-js#stage-4-proposals.
2017-10-16 09:11:39 +02:00
Jonas Jenwald
2f32131601 Replace our WeakMap polyfill with the one from core-js
Since we're already using core-js elsewhere in `compatibility.js`, we can reduce the amount of code we need to maintain ourselves.

https://github.com/zloirock/core-js#weakmap
2017-10-15 10:22:06 +02:00
Yury Delendik
fab59e0f91 Revert "Closes all promises/streams when handler is destroyed." 2017-10-06 11:55:28 -05:00
Jonas Jenwald
5b67c7594c Remove the unused Util.sign function from src/shared/util.js
This has been completely unused since commit 10bb6c9ec0, in PR 2505, more than four and a half years ago.
2017-10-01 15:58:03 +02:00
Yury Delendik
71b0e4e818 Closes all promises/streams when handler is destroyed. 2017-09-28 16:45:04 -05:00
Jonas Jenwald
cfb4955a92 Replace the isArray helper function with the native Array.isArray function
*Follow-up to PR 8813.*
2017-09-01 20:27:13 +02:00
Jonas Jenwald
11408da340 Replace the isInt helper function with the native Number.isInteger function
*Follow-up to PR 8643.*
2017-09-01 16:52:50 +02:00
Mukul Mishra
3516a59384 Adds fetch stream logic for networking part of PDF.js 2017-08-29 22:56:48 +05:30
Mukul Mishra
efad0c7a40 Set this.isCancelled in close method of streamSink. 2017-08-24 13:51:27 +05:30
Yury Delendik
57bc3296f4 Moves global scope out of shared/util. 2017-08-22 18:20:52 -05:00
Jonas Jenwald
be36c60e0f Polyfill Uint8ClampedArray using core-js
https://github.com/zloirock/core-js
2017-08-14 16:19:55 +02:00
Tobias Schneider
da44d10af1 Fallback to plain object for globalScope. 2017-08-08 09:17:48 -07:00
Yury Delendik
a1dfbec532 Properly cancel streams and guard at getTextContent. 2017-08-03 16:36:46 -05:00
Yury Delendik
6beb925f0b Checks Edge support for streams. 2017-08-03 08:48:51 -05:00
Yury Delendik
01b47d9012 Use streams-lib as polyfill 2017-07-28 11:54:33 -05:00
Mukul Mishra
109106794d Adds Streams API support for networking task of PDF.js project.
network.js file moved to main thread and `PDFNetworkStream` implemented
at worker thread, that is used to ask for data whenever worker needs.
2017-07-28 02:32:30 +05:30
Mukul Mishra
568b0b6a42 Adds ready capability rejection logic for stream sink. 2017-07-25 02:07:38 +05:30
Jonas Jenwald
f2270252c7 Add Number.isNaN and Number.isInteger polyfills in compatibility.js, since the Streams polyfill relies on them
Without this, the Streams polyfill will fail in Internet Explorer when the code-paths containing these methods are used.
2017-07-13 12:02:14 +02:00
Rob Wu
742ed3d1c9 Remove __pdfjsdev_webpack__, use webpack options
`__pdfjsdev_webpack__` was used to skip evaluating part of an AST,
in order to not mangle some `require` symbols.
This commit removes `__pdfjsdev_webpack__`, and:

- Uses `__non_webpack_require__` when one wants the output to
  contain `require` instead of `__webpack_require__`.
- Adds options to the webpack config to prevent "polyfills" for
  some Node.js-specific APIs to be added.
- Use `// eslint-disable-next-line no-undef` instead of `/* globals ... */`
  for variables that are not meant to be used globally.
2017-07-09 16:35:48 +02:00
Yury Delendik
d028c26210 Removes error() 2017-07-07 09:40:24 -05:00
Yury Delendik
e2ca894fec Merge pull request #8488 from mukulmishra18/streams-getTextContent
Streams get text content
2017-06-23 12:52:13 -05:00
Yury Delendik
679ffc84f6 Merge pull request #8544 from Rob--W/compatiblity-safari-strict-error
compatibility.js: Rename parameters in JURL
2017-06-19 10:34:33 -05:00
Rob Wu
f912f89e69 compatibility.js: Rename parameters in JURL 2017-06-19 17:03:41 +02:00
Jonas Jenwald
73234577e1 Rename map to _map inside of Dict, to make it clearer that it should be regarded as a "private" property 2017-06-17 17:32:00 +02:00
Mukul Mishra
0c13d0ff46 Adds Streams API in getTextContent to stream data.
This patch adds Streams API support in getTextContent
so that we can stream data in chunks instead of fetching
whole data from worker thread to main thread. This patch
supports Streams API without changing the core functionality
of getTextContent.

Enqueue textContent directly at getTextContent in partialEvaluator.

Adds desiredSize and ready property in streamSink.
2017-06-17 20:03:27 +05:30
Yury Delendik
0c93dee0de Merge pull request #8515 from yurydelendik/bloborigin
Adds special case for origin of blob to the compatibility URL.
2017-06-16 11:21:45 -05:00
Yury Delendik
631e6bebff Fixes WeakMap polyfill (and improves PDFWorker port check). 2017-06-13 09:36:58 -05:00
Yury Delendik
b44848b918 Adds special case for origin of blob to the compatibility URL. 2017-06-13 08:19:46 -05:00
Yury Delendik
db7a770542 Additional check in globalScope detections 2017-06-12 10:14:46 -05:00
Mukul Mishra
bbd9968f76 Added sendWithStream method in MessageHandler.
Adds functionality to accept Queueing Strategy in
sendWithStream method. Using Queueing Strategy we
can control the data that is enqueued into the sink,
and hence regulated the flow of chunks from worker
to main thread.

Adds capability in pull and cancel methods.
Adds ready and desiredSize property in streamSink.

Adds unit test for ReadableStream and sendWithStream.
2017-06-07 21:05:27 +05:30
Jonas Jenwald
f20d2cd2ae Fix inconsistent spacing and trailing commas in objects in remaining src/ files, so we can enable the comma-dangle and object-curly-spacing ESLint rules later on
http://eslint.org/docs/rules/comma-dangle
http://eslint.org/docs/rules/object-curly-spacing

Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead.

Please note: This patch was created automatically, using the ESLint `--fix` command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch.

```diff
diff --git a/src/display/canvas.js b/src/display/canvas.js
index 5739f6f2..4216b2d2 100644
--- a/src/display/canvas.js
+++ b/src/display/canvas.js
@@ -2071,7 +2071,7 @@ var CanvasGraphics = (function CanvasGraphicsClosure() {
       var map = [];
       for (var i = 0, ii = positions.length; i < ii; i += 2) {
         map.push({ transform: [scaleX, 0, 0, scaleY, positions[i],
-                 positions[i + 1]], x: 0, y: 0, w: width, h: height, });
+                   positions[i + 1]], x: 0, y: 0, w: width, h: height, });
       }
       this.paintInlineImageXObjectGroup(imgData, map);
     },
diff --git a/src/display/svg.js b/src/display/svg.js
index 9eb05dfa..2aa21482 100644
--- a/src/display/svg.js
+++ b/src/display/svg.js
@@ -458,7 +458,11 @@ SVGGraphics = (function SVGGraphicsClosure() {

       for (var x = 0; x < fnArrayLen; x++) {
         var fnId = fnArray[x];
-        opList.push({ 'fnId': fnId, 'fn': REVOPS[fnId], 'args': argsArray[x], });
+        opList.push({
+          'fnId': fnId,
+          'fn': REVOPS[fnId],
+          'args': argsArray[x],
+        });
       }
       return opListToTree(opList);
     },
```
2017-06-02 12:32:18 +02:00
Mukul Mishra
c9f44f30e5 Adds streams-lib polyfill and exports ReadableStream from shared/util.
Added test for ReadableStream.

Adds ref-implementation license-header in streams-lib
and change gulp task to copy external/streams/ in build/
external/streams/ and build/dist/external/streams folder.

Adds README.md and LICENSE.md
2017-05-20 00:26:34 +05:30
巴里切罗
8d5d97264e fix(svg) adjust strategy for decoding JPEG images 2017-05-08 11:32:44 +08:00
Jonas Jenwald
60b14f526e Convert the files in the /src/shared folder to ES6 modules 2017-05-04 21:07:59 +02:00
Jonas Jenwald
6c81b8e6dd Replace unnecessary bind(this) and var self = this statements with arrow functions in remaining src/ files 2017-05-03 23:12:35 +02:00
Jonas Jenwald
ee09336f32 Restore the URL.createObjectURL check to the createObjectURL utility function (issue 8344)
This is a regression from commit 3888a993b1.

It turns out the even though we have a `URL` polyfill, it's still dependent on the existence of native `URL.{createObjectURL, revokeObjectURL}` functions.
Since no such thing exists in Node.js, our `createObjectURL` utility function breaks there.
2017-04-27 20:57:15 +02:00
Jonas Jenwald
7bee0c2aa3 Enable the object-shorthand ESLint rule in src/shared
Please see http://eslint.org/docs/rules/object-shorthand.

For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-25 16:07:59 +02:00
Jonas Jenwald
3888a993b1 Remove the URL checks in the createObjectURL utility function, since the URL polyfill have made them redundant
Also, this changes `createBlob` to throw when `Blob` isn't supported.
2017-04-20 10:16:06 +02:00
Yury Delendik
30bee9fe0c Moves Uint32ArrayView and hasCanvasTypedArrays into compatibility.js. 2017-04-14 10:04:52 -05:00
Jonas Jenwald
3a302fdb53 Correctly detect if requestAnimationFrame is supported in compatibility.js (issue 8272)
This is a regression from PR 8222.

Fixes 8272.
2017-04-11 17:01:35 +02:00
Travis Grathwell
bd70a73d43 ios: Patch cancelAnimationFrame whenever fakeRequestAnimationFrame is used
The existing implementation of fakeRequestAnimationFrame
did not return a timer ID, so the frame could not be cancelled
if you wanted to cancel it. But if you do want to cancel it,
it needs to be cancelled through clearTimeout instead of
cancelAnimationFrame, because the timer IDs are different.

Signed-off-by: Jonathan Barnes <jbarnes@pivotal.io>
2017-03-31 15:31:04 -07:00
Jonas Jenwald
a7c19d9cbb Adjust the yoda ESLint rule to apply to inequalities as well
I happened to notice that some inequalities had the wrong order, and was surprised since I thought that the `yoda` rule should have caught that.
However, reading http://eslint.org/docs/rules/yoda#options a bit more closely than previously, it's quite obvious that the `onlyEquality` option does *exactly* what its name suggests. Hence I think that it makes sense to adjust the options such that only ranges are allowed instead.
2017-03-19 13:27:14 +01:00
Yury Delendik
facefb0c79 Move compatibility code to the shared/compatibility.js. 2017-02-23 19:18:44 -06:00
Jonas Jenwald
9082f08e37 Enable running the cmap unit-tests on Travis by utilizing a NodeCMapReaderFactory 2017-02-17 23:15:36 +01:00
Jonas Jenwald
769c1450b7 [api-minor] Refactor fetching of built-in CMaps to utilize a factory on the display side instead, to allow users of the API to provide a custom CMap loading factory (e.g. for use with Node.js)
Currently the built-in CMap files are loaded in `src/core/cmap.js` using `XMLHttpRequest` directly. For some environments that might be a problem, hence this patch refactors that to instead use a factory to load built-in CMaps on the main thread and message the data to the worker thread.

This is inspired by other recent work, e.g. the addition of the `CanvasFactory`, and to a large extent on the IRC discussion starting at http://logs.glob.uno/?c=mozilla%23pdfjs&s=12+Oct+2016&e=12+Oct+2016#c53010.
2017-02-16 10:55:35 +01:00
Jonas Jenwald
bc736fdc7d Adjust the brace-style ESLint rule to disallow single lines (and also enable no-iterator)
See http://eslint.org/docs/rules/brace-style.
Having the opening/closing braces on the same line can often make the code slightly more difficult to read, in particular for `if`/`else if` statements, compared to using new lines.

This patch also, for consistency with `mozilla-central`, enables the [`no-iterator`](http://eslint.org/docs/rules/no-iterator) rule. Note that this rule didn't require a single code change.
2017-02-04 15:53:08 +01:00
Tim van der Meij
1948a53ebb Merge pull request #7973 from Snuffleupagus/eslint_spaced-comment
Enable the `spaced-comment` ESLint rule
2017-01-22 21:58:42 +01:00
Mukul Mishra
4e38200030 Fix #7978: Fixes ESLint yoda rule for the URL polyfill. 2017-01-21 22:47:28 +05:30