Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1170063.
The bug only mentions the <kbd>Meta</kbd> key, but given that a similar situation can occur for <kbd>Ctrl</kbd>, it seemed reasonable to also handle that case in the same patch.
The only possible caveat with the patch is that because of the use of `shadow`, things won't work perfectly if either of the prefs are changed *while* the viewer is active. In this case a reload is required in order for it to work correctly, but given that the issue this patch fixes should be quite rare anyway, that seems OK.
Currently in the tests which check that incorrect passwords are rejected, we don't ensure that the exceptions thrown are the ones we expect. This patch improves the current situation, so that we actually can be sure that the code "fails" in the correct way.
*Note:* This patch also fixes some cases of weird indentation in the file.
Currently non-embedded ArialBlack fonts are not rendered bold enough, compared to e.g. Adobe Reader.
The issue is that we set the font weight to `bolder`, but since that is actually relative to the font weight of the parent, the result is that there's no practical difference from just using `bold`.
This patch attempts to address that, by explicitly setting the font weight to the maximum value instead (see https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight).
*Note:* I expect one test "failure" in `issue5801`, which in this case is an improvement, since that PDF file uses ArialBlack.
Fixes 6068.
The most notable issue with the font in question is that the `differences` array contains lots of strange entries (of the type `uniXXXX`, instead of proper glyph names).
The Chrome extension is stable and has been around for a few years, so
the ancient note about the extension being experimental can be removed.
Also be a bit more specific about who maintains the Chrome extension,
to make it easier for external contributors to find who is responsible
for the development and maintenance of the PDF.js Chrome extension.
Currently `PDFLinkService` requires access to a `PDFHistory` instance in order for it to work correctly (and to avoid errors). If we want `PDFLinkService` to be more useful in custom viewers, I don't think that we actually want to force it to have a `PDFHistory` instance.
Hence this patch, which contains a very simply approach to make `PDFHistory` optional.
For some reason, https://bugzilla.mozilla.org/show_bug.cgi?id=1167053 changed methods of `NetUtil` yet *again*. This patch thus attempts to handle those changes, while keeping the addon backwards compatible.
I've tested this using all current Firefox versions (Nightly, Aurora/DevEdition, Beta, Release, ESR), and things still appears to work correctly.
Jonas Jenwald
Yury Delendik
Tim van der Meij
Brendan Dahl
Rob Wu
Timothy Gu