Closed mijoharas closed 4 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:
(our extensions can communicate with each other using chrome.runtime.onMessageExternal
and chrome.runtime.sendMessage
)
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?
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).
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.
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".
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