search

mozilla / pdf.js

PDF Reader in JavaScript
https://mozilla.github.io/pdf.js/
Apache License 2.0
48.42k stars 9.97k forks source link

Is pdf.js supposed to capture all key events? #4555

Closed mijoharas closed 4 years ago

mijoharas commented 10 years ago

use of pdf.js with an extension (in chrome) seems to capture all key events. This shadows functions of the extension, such as back, forward (in history) and switch tab left and right. Apparently this used to work. https://github.com/philc/vimium/issues/723#issuecomment-39363488

Rob--W commented 10 years ago

The Chrome extension was initially implemented by aborting the request and replacing the content with the viewer. With this approach, the URL was preserved. This came with a bunch of other problems, so I ultimately switched to a different approach.

Currently, PDFs are redirected to chrome-extension://[EXTENSIONID]/../viewer.html?file=path/to/file.pdf. Chrome extensions cannot run in the context of other Chrome extensions (http://crbug.com/77440), so your Vimium extension doesn't work.

I'm open to suggestions for collaboration if you can think of a decent method of integrating Vimium functionality in PDF.js for Vimium users. I'll assess the solution by the following criteria:

  1. Security. I reject all methods that may compromise the user's security.
  2. Conflicts. The solution should not interfere with PDF.js' functionality.
  3. Performance. The solution must not have a (significant) negative performance impact, especially not for users who did not install Vimium.

(our extensions can communicate with each other using chrome.runtime.onMessageExternal and chrome.runtime.sendMessage)

mijoharas commented 10 years ago

Cool, thanks for your response. That makes sense and I agree with your 3 points. Let me think about what approaches we could take to deal with this and get back to you (while the chrome messaging platform is there and can work it feels like we're "special casing" it too much going in that direction. Obviously as general a method as possible is most desirable for future people to hack away on. I suppose we could build a nice general api into this interface, but that's why I need to think a bit, any suggestions/ideas are obviously appreciated). You couldn't direct me to the issues/reasons for the decision to redirect to chrome-extension://.* url so that I can educate myself on the specifics?

Rob--W commented 10 years ago

The original support for Chromium was introduced with https://github.com/mozilla/pdf.js/pull/3017. Later, the method was changed in https://github.com/mozilla/pdf.js/pull/3751 to improve the speed of showing the PDF reader (for some PDFs, it took quite a while before the PDF finally showed up).

michaelfresco commented 8 years ago

I hope that the J/K keybindings can be harmonized on PDF.js. The vimium implementation is really better than the way pdf.js does it right now.

In practice that would mean that you'd:

Where x could be set to be something like 4 or 5 lines.

dragon788 commented 8 years ago

I'd like to see this improved as well, I see that j/k are scrolling, but it's currently a page at a time, while the arrow keys correctly scroll just a small portion of the document at a time. I do love the improvement over the Chrome reader and Adobe since my hands rarely leave the keyboard, but I would like to avoid leaving the home row as much as possible as well and the arrow keys (even on my custom keyboard layout) are just "a bridge too far".