After the latest update of the minimum supported Firefox version, the development addon is no longer being signed. Hence this patch attempts to address that, by pinning the `minVersion` to a specific version number instead.
*Please note:* The version numbers were taken from https://addons.mozilla.org/en-US/firefox/pages/appversions/, so it ought to have worked.
At this point in time, trying to keep the development addon compatible with prior Firefox versions is already quite difficult and will become even harder very soon.
Please keep in mind that since Firefox 57, only WebExtensions are allowed/possible to install. The only exceptions are Firefox Nightly, with the `xpinstall.signatures.required` preference[1] set to `false`, and the (as of this writing) current ESR release.[2]
With the current compatibility situation, we thus need to effectively support both Nightly *and* ESR in the addon, while trying to keep up with current/upcoming changes in `mozilla-central`. With old addons no longer being officially supported, the amount of old code being removed/refactored is now increasing quite quickly.
*Please note:* The changes proposed here was to a large extent prompted by bugs such as:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1431533 (already landed)
- https://bugzilla.mozilla.org/show_bug.cgi?id=767640 (already landed)
- https://bugzilla.mozilla.org/show_bug.cgi?id=1432992 (still open)
Upstreaming all of those changes for the `MOZCENTRAL` version of PDF.js, while also keeping the Firefox addon running in older versions of the browser, would quickly become non-trivial.
Since we're using the ruleset from `eslint-plugin-mozilla` for the addon files, which is enforced in `mozilla-central`, we must ensure that the neccessary changes are upstreamed to the PDF.js repo such that the `mozilla-central` version of PDF.js can still be updated without failures.
Trying to feature detect, for the `FIREFOX` build target, some of the changes in the referenced bugs would probably become both quite messy and (not to mention) difficult. E.g. with the upcoming and automatically defined `Cc, Ci, Cu, Cr` variables, any sort of feature detection might be tricky since those need to be defined in the global scope of the files in question.
Finally, given the amount of effort that we'd now need to spend to even attempt to keep the Firefox addon compatible, I just don't think it's worth the effort any more. Especially since the number of people that have, thus far, been doing this work is *very* low and those resources would be better spend elsewhere.
Unfortunately, this probably means that the development addon will no longer be compatible with release versions of Seamonkey. However the README has already mentioned, for quite some time, that support isn't guaranteed.
*In closing:* For all of the reasons mentioned above, I thus propose that we reduce the maintenance burden of the Firefox addon by only supporting the current Firefox Nightly.
---
[1] While the preference exists, and can be toggled, its value is ignored in non-Nightly versions of Firefox.
[2] There's unbranded builds of e.g. the release/beta versions of Firefox, where old and non-WebExtensions addons can be installed. However those builds can probably be assumed to be officially unsupported, and thus not recommended for users.
Merge ftp and file handler now their implementations are identical.
Remove redundant comment (the referenced Chrome bug has been fixed
a long time ago - https://crbug.com/302548 ).
Since multiple empty lines is virtually unused in the code-base, and the few cases that do exist look like "typos", let's enforce greater consistency here; please see https://eslint.org/docs/rules/no-multiple-empty-lines.
While this doesn't actually fix the underlying issue, it should prevent the ESLint errors and thus make future PDF.js updates easier.
Compared to updating (and testing) the preprocessor, this seems like a reasonable workaround given its simplicity.
See Bug 1389443 for more information. This allows us to register
PdfJs without waiting for file IO in nsHandlerService to finish.
Once that file IO is finished, we can set everything up properly
and double-check the registration.
Note that the PageMode, as specified in the API, will only be honoured when either: the user hasn't set the `sidebarViewOnLoad` preference to a non-default value, or a non-default `sidebarView` entry doesn't exist in the view history, or the "pagemode" hash parameter is included in the URL.
Since this is new functionality, the patch also includes a preference (`disablePageMode`), to make it easy to opt-out of this functionality if the user/implementor so wishes.
Add UI for the cursorToolOnLoad pref in the UI of the Chrome extension.
Add logic to migrate the enableHandToolOnLoad pref to cursorToolOnLoad.
For past values in the mutable extension storage area:
1. If enableHandToolOnLoad=true, save cursorToolOnLoad=1.
2. Remove enableHandToolOnLoad.
For the managed extension storage, which is immutable since it is based
on administrative policies, use the following logic:
1. If enableHandToolOnLoad=true and cursorToolOnLoad=0 (default).
set cursorToolOnLoad=0 and assume enableHandToolOnLoad=false.
2. As usual, managed preferences can (and will) be overridden by the user.
The first migration logic is in extensions/chromium/options/migration.js
and can be removed after a few months / less than many years.
The second migration logic is in web/chromecom.js, and should be kept
around for a long while (many years).
The need for this migration logic arises from the change by:
https://github.com/mozilla/pdf.js/pull/7635
http://eslint.org/docs/rules/comma-danglehttp://eslint.org/docs/rules/object-curly-spacing
Given that we currently have quite inconsistent object formatting, fixing this in 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/extensions/firefox/content/PdfStreamConverter.jsm b/extensions/firefox/content/PdfStreamConverter.jsm
index ea91a71a..0d59dad1 100644
--- a/extensions/firefox/content/PdfStreamConverter.jsm
+++ b/extensions/firefox/content/PdfStreamConverter.jsm
@@ -773,7 +773,8 @@ class RequestListener {
response = function sendResponse(aResponse) {
try {
var listener = doc.createEvent("CustomEvent");
- let detail = Cu.cloneInto({ response: aResponse, }, doc.defaultView);
+ let detail = Cu.cloneInto({ response: aResponse, },
+ doc.defaultView);
listener.initCustomEvent("pdf.js.response", true, false, detail);
return message.dispatchEvent(listener);
} catch (e) {
```
With the current way that the `HandTool` is implemented, if someone would try to also add a Zoom tool (as issue 1260 asks for) that probably wouldn't work very well given that you'd then have two cursor tools which may not play nice together.
Hence this patch, which attempts to refactor things so that it should be simpler to add e.g. a Zoom tool as well (given that that issue is marked as "good-beginner-bug", and I'm not sure if that really applies considering the current state of the code).
Note that I personally have no interest in implementing a Zoom tool (similar to Adobe Reader) since I wouldn't use it, but I figured that it can't hurt to make this code a bit more future proof.
This is a downstream change introduced in [1]. That mozilla bug is adding a new property to channel's loadinfo object (nsILoadInfo) that protocol handlers has to set on channels when originalURI on the result channel is set to a different URI than the channel has been created for.
Existence of the new property on nsILoadInfo depends on landing [1].
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1319111
Please note that I used the addon debugger to set a breakpoint in the `unload` function, in order to ensure that `this` still correctly refers to the `FindEventManager` scope.
Please see http://eslint.org/docs/rules/object-shorthand.
Unfortunately, based on commit 9276d1dcd9, it seems that we still need to maintain compatibility with old Node.js versions, hence certain files/directories that are executed in Node.js are currently exempt from this rule.
Furthermore, since the files specific to the Chromium extension are not run through Babel, the `/extensions/chromium/` directory is also exempt from this rule.
In https://bugzilla.mozilla.org/show_bug.cgi?id=1355216, the *third* parameter of `Services.obs.addObserver` was made optional.
However, omitting it in Firefox versions *without* that patch causes failures that completely prevents the addon from working (it won't even load).
As far as I can tell, there isn't *any* way to detect ahead of time if the third parameter can be safely omitted, hence we're forced to fallback to manually checking the version number :-(
*Note:* Since the `PdfJs.jsm` file is only used in the `MOZCENTRAL` build, we at least don't need to add any compatibility hacks there.
If we only invoke the bootstrap-enabled script when PdfJs.enabled is
true, then we don't need to check it again in the script.
This avoids a sync IPC call to the parent process.
It also keeps PdfJs.jsm from importing PdfjsContentUtils.jsm in the
child process until it is actually needed, which is one steps towards
not loading it until it is really needed.
pdfjschildbootstrap.js will always be run, but
pdfjschildbootstrap-enabled.js will only be run if PdfJs.enabled is
true. This will let us avoid some work in the child process in the
next patch.
This will need to be landed in the mozilla-central repository at the
same time as a change to nsBrowserGlue.js. See bug 1352218.
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.
The last (and only) usage of `MOZ_CENTRAL` was removed in PR 3036, so it's been unused for almost four years now.
If we need to have different code-paths for `FIREFOX`/`MOZCENTRAL` builds, the preprocessor should (and has) been used instead.
When a blob or data-URL is opened with the extension, viewer.html
rewrites the URL. But when the viewer is refreshed (e.g. F5), Chrome
would fail to display the viewer because the extension router was not
set up to recognize such URLs.
Now it is.
