Port to Firefox about vimium-c HOT 34 CLOSED

Hello.

The firefox version of Vimium C has been released: https://addons.mozilla.org/zh-CN/firefox/addon/vimium-c/. Though it's still in beta.

Here're some things to do:

• linkhints@forceNewTab can not work because of Firefox's popup blocker
• global browser shortcuts seem to fail to work
• test injecting into other web-extensions
• wrapping around when finding text on Firefox (seems no native support of this function) (solved)

from vimium-c.

Once Vimium C has a "firefox" branch and it has been merged into the master branch - if you build Vimium C by yourself, (or unzip the CRX file https://github.com/gdh1995/vimium-c/releases/download/v1.69.2/vimium-c_1.69.2.crx), it' working on Firefox ^_^

Some lacking features:

• all operations requiring to read the system clipboard
  • the elegant reading on Chrome is disallowed on Firefox
  • and then I haven't implemented an uglier method
• for LinkHints, open-in-new-tab may have no effects
  • Firefox has a much annoying popup-window blocker and does not trust mouse events from such extensions

Warnings:

• currently I haven't made enough tests, so it may break and throw errors on some unpredictable conditions.

Plans:

• I might release a version on Firefox's extension market when I test a lot and use Firefox + Vimium C for a few weeks.

from vimium-c.

Vomnibar's delay

The delay of Vomnibar is for lower CPU cost, and if it's smaller than 100~200ms, I think it will means to do a query every time you input a character, and make the backend returns many unused suggestions - most suggestions occur and then get removed in the next 100ms, so you can not read them or even see them.

I'll add a hidden option to control it - Vimium C now has too many options, and some are not so important and then I don't want to list them on the options page. I promise that it's easy to configure these hidden options.

on GitHub

Only the first line of the log is related about Vimium C, and it is indeed a fault of Vimium C, but not Github's. I'll solve it in days.

Now my local Vimium C still works on Firefox 66.0.2 x64 on Win 10.

from vimium-c.

Now, the latest version v1.74.9 of Vimium C will try to focus Vomnibar for at most 6 times on activating, and I expect this can fix the focus issue you met.

As for hanging issue, I've found some bad code and fixed them, but up to now, the feature of customized vomnibar page has still bugs - a web page vomnibar may fail to load sometimes.

from vimium-c.

Um, the issue seems not to exist on Firefox 91.(6+) and 96, but I haven't re-checked it on the lastest Firefox 99.

So the most possible reason is: on a click event, the website did not open a link but run its JS code to do something it want.

Or maybe you met another problem of Vimium C. Feel free to open a new issue and report those websites and test steps.

from vimium-c.

from vimium-c.

Well, most things have been fixed and I've published v1.74.0.

Left issues to do:

• wrapping around when finding text on Firefox (seems no native support of this function)

from vimium-c.

Few issues that I've stumbled upon:

1. New tab acts a bit jerky. I configured new URL tab to "about:blank" and then I press ctrl-t, a new tab is created but it looks like for a brief moment another Extension's tab is created and closed the very same moment. Unfortunately, I notice these abrupt, sharp movements and it feels weird, not as smooth as without the extension. I can record a gif if you need to have a look at it.

2. After a while (very soon, actually) shortcuts either stop working or Vomnibar (ctrl-T, or ctrl-O pages) are displayed on the wrong tabs. For example, I'm on tab 1, then I switch to tab 2, press "ctrl-T" and nothing happens. I switch to tab 1 and I see that popup menu is on tab 1 instead of my currently active tab 2. Also, Firefox's zoom level indicator grows and shrinks for a brief moment. In other cases shortcuts just point blank stop working, including such keys as ctrl-r, ctrl-shift-r.

Could this be a conflict with some other extension? How can I help you track down the issue?

from vimium-c.

Thanks for your feedback.

The first is Vimium C's inner page, and it closes itself immediately after opening the "new tab" you've configured. This is because Firefox will focus its address bar on creating a new tab page on Ctrl+T, while I think this feature is annoying and find this method (an temporary tab) to let the real page get focus back.

The second: it's weird. Could you provide the version of your Firefox and operating system? Are you saying (only 4) global shortcuts or Vimium C's common key mappings (which only work mainly on http(s):// and file:// pages, but not about:* pages).

By the way, do you like the behavior of native Firefox that it focuses the address bar once it creates a "new tab"? Some of Chrome users reported they like it while some others (including me) don't.

from vimium-c.

Firefox will focus its address bar on creating a new tab page on Ctrl+T

Yeah, that's exactly the old behavior that I'd like to have. Is it possible to configu Vimimum C to have it?

version of your Firefox and operating system

Firefox 66.0.2 (64-bit) on ArchLinux and Ubuntu 16.04.

Are you saying (only 4) global shortcuts or Vimium C's common key mappings

I tried few global shortcuts, such as reload on ctrl-r and few Vimium-specific, such as ctrl-T, ctrl-O. I noticed that behavior on https pages (github.com, to be specific). I'll keep using the extension to see if I can provide a more reliable way to reproduce the problem or if I notice any particular pattern when it occurs.

By the way, do you like the behavior of native Firefox that it focuses the address bar once it creates a "new tab"?

Very much! I type ctrl-t and when my cursor in the address bar, I'm ready to type a URL. Now I have to additionally press ctrl-l to focus the address bar. If you could leave the default behavior as an option that'd be great!

from vimium-c.

Global shortcuts

Every webextension can provide at most 4 global shortcuts to Firefox / Chrome, and if a user configures the key binding, he/she can use the key to tell a webextension to do something even when the address bar / browser icon area is being focused.

These shortcuts can be configured on about:addons on Firefox (chrome://extensions/shortcuts on Chrome):

But, although on Chrome you may bind any key to a shortcut (even override the Chrome's default bindings), on Firefox you can't - an Alt+V on Firefox always trigger the menu item "View" on Firefox for Windows.

Vimium C's common key mappings:

The can only work in "web" pages and only when a page content gets focused. It's because Firefox doesn't allow Vimium C to run JavaScript code on its private pages (like about:preferences and about:addons). Besides, when the address bar of Firefox window gets focuses, Vimium C's content script code can not get any keyboard messages, so it won't be able to response on your keys.

So which kind of keys your problem is about? The global ones or common ones?

open and focused

I'll have a try. Maybe I need to publish two versions of Vimium C - one overrides the New Tab page, and the other does not ...

from vimium-c.

The global ones or common ones?

Then it must be common ones -- I didn't even know you can assign custom global shortcuts, wow.

What I'm noticing more and more is that Vimium kinda lags behind my actions. I press ctrl-T nothing pops up and I switch to another tab. Then I switch to a third tab, and back to the first one, and I see that Vimium window opened on the first tab but with huge lag. Sometimes it even opens in another tab as if another tab is still focused and keyboard input goes there... I can say that my usage of Firefox may be a bit unusual since I currently have 560 tabs open. Most of them are suspended (not activated after the previous browser restart), but still.

Also, this is very subjective, but it feels like filtering is a bit less responsive. With Vimium C I feel like I have to wait longer in ctrl-T window after I typed something, as if there is a bigger delay before filtering is applied. That's uncomfortable.

from vimium-c.

Um, Vimium C should have a comfortable performance. Let's debug it:

• are you using the "recommended settings"? if so, open the Vimium C Options page and check the "Preferred Vomnibar Page"
• if you ever configured "Preferred Vomnibar Page", reset it (deleting all and it'll be reset) and save options
• if Vomnibar initing is still slow, please try opening Vomnibar on Vimium C Options page and compare the time with the case of opening Vomnibar on normal webpages
• finally, open Vomnibar, wait it loading, and then open the FireFox Developer Tools (menu -> web developer -> web console), please capture the window and display all of its message text here.

The Vomnibar has a limit on auto-completing frequency, about 500 milli seconds (half a second). This means both input actions on timestamp 0ms and 480ms will trigger the same completing action on timestamp 500ms. So you do need to wait a while.

On the official Vimium, the timer's 150ms. Vimium C is able to achieve the same speed, and this 500ms is just what I wrote 2~3 years ago.

from vimium-c.

The Vomnibar has a limit on auto-completing frequency, about 500 milli seconds (half a second). This means both input actions on timestamp 0ms and 480ms will trigger the same completing action on timestamp 500ms. So you do need to wait a while

Wow, that's a tremendous delay! Is this configurable? Having 150ms delay is much, much more confortable to me. Even that is a lot, I think. I'd set it to 50ms...100ms max if I could. Otherwise the delay is very noticeable.

if Vomnibar initing is still slow

I've reset the options just in case and if I notice it gets slow, I'll provide the capture of the window as you suggested.

from vimium-c.

I've just noticed this in browser's console of github page:

Some functions of Vimium C may not work because  /act  is sandboxed. vimium-c.js:1:81919
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).
act:1:1
Content Security Policy: The page’s settings blocked the loading of a resource at data:font/woff2;base64,d09GMgABAAAAADKgA… (“font-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at data:font/woff2;base64,d09GMgABAAAAADB4A… (“font-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at data:font/woff2;base64,d09GMgABAAAAABDIA… (“font-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at data:font/woff2;base64,d09GMgABAAAAABkIA… (“font-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at data:font/woff2;base64,d09GMgABAAAAABqsA… (“font-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at data:font/woff2;base64,d09GMgABAAAAABUkA… (“font-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at data:font/woff2;base64,d09GMgABAAAAAB4AA… (“font-src”).
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.github.com/_private/browser/stats. (Reason: CORS request did not succeed).[Learn More]

Vimium shortcuts on any github page stopped working, though they worked several hours before.

from vimium-c.

Another glitch that I noticed is that sometimes popup window does not get keyboard focus. I press ctrl-T, but my keypresses are still being handled by the original page, not Vimium. I observed such behaviour on calendar.google.com and on gitlab pages. Not 100% reproduceable, unfortunately.

from vimium-c.

Then what command do you map <c-t>?

from vimium-c.

Sorry, I meant to write "shift-T" -- recent tabs.

from vimium-c.

In usual cases, Vimium C has a much higher priority than pages' scripts, so the Shift+T should always be received by Vimium C. But, if on your keyboard "Caps lock" is on, a "Shift+T" will be treated as "t". So you may add map t Vomnibar.activate for further tests.

from vimium-c.

I've upgraded Vimium C to v1.74.2 , and it includes two new options: "Focus web page when creating a new tab" and Vomnibar settings.

Thanks again for your try.

Now Vimium C just works on github.com on Firefox. It is a simple working around, and a feature of Vimium C is lost on such websites. But, there seems no perfect solution up to now.

from vimium-c.

Thank you for your huge effort to make this extension better, I appreciate it very much!

I've tried the new version on two machines. On one it's been running OK so far, but on the other one shortcuts are not working and the little window that pops up when you click on the extension icon is blank, the one where you could quickly add an ignore rule (even though I manually added https://mail.google.com there).

On top of that, if I press, for example, shift-T (Vomnibar shortcut), input gets completely broken and I can't even type in an input/edit box (I had to reopen this issue URL several times before I could finish my comment).

Unfortunately, there is nothing in the console logs. Maybe there is a background page of the extension? I couldn't find it in the extension options (similarly to background page in chrome extensions).

from vimium-c.

Updated:

• The "broken" caused by Vomnibar still needs more tests.
• The crash of popup window has been confirmed. I'll solve in days.

As for the log, recently I noticed that Firefox collect all logs (from both content scripts and background page) of all extensions into a single list, and you can see them if only you debug any one webextension's background page... It's very annoying for me, and there're many other inconvenient things on Firefox, compared to Chrome. This is one of the reasons why I haven't worked on Firefox until this two months.

You need to open "about:debugging" on Firefox and there you can click "debug" button of the Vimium C card.

• Then Firefox will show a confirmation dialog asking you if you agree to debug it
• And a Developer Tools window is showing but keeps blank unless you confirm the dialog
• If you can not see the dialog, use "Alt+T" to switch among program windows and you may find it
• When the Developer Tools gets ready, the "console" panel will show lots of info, while most should not be related with Vimium C itself
• please put all of them here, though, and I'll try to find real crashes.

from vimium-c.

Unfortunately, there is nothing useful in background page log... Here is what I got:

Webconsole context has changed

Use of nsIFile in content process is deprecated.
NetUtil.jsm:259:12
The ‘content’ attribute of Window objects is deprecated.  Please use ‘window.top’ instead. _generated_background_page.html
onmozfullscreenchange is deprecated. _generated_background_page.html
onmozfullscreenerror is deprecated. _generated_background_page.html
Navigated to about:blank
Webconsole context has changed
Navigated to moz-extension://32d9d872-29b8-4f61-b823-d0f3b0b17f75/_generated_background_page.html
Webconsole context has changed

I cleared the log, then I disabled and enable the extension. The message Webconsole context has changed is displayed when trigger the extension (enable/disable), but it shows nothing besides of that upon the initialization or upon any keypress (I tried t, shift-T, o, shift-O, p, x).

Having toyed with it a bit more, I found out that if I reload the tab and if I try "t" (new tab) or "p" (paste URL and go) first, they work. But as soon as I type shift-T, o, shift-O, the extension becomes silent and starts to ignore all the keys from now on.

from vimium-c.

The slience means Vomnibar failed in loading, and got stuck in an intermediate state, while Vimium C failed in detecting this crash.

You may press <esc> to exit this status, and then most other commands will work again, but Vomnibar keeps broken.

Just a tip: if you reload / disable+enable an webextension, then the developer tools becomes not reliable, so I usually: close the dev tools window, reload Vimium C, and click the "debug" button.

from vimium-c.

I still fail to reproduce the crash caused by Vomnibar on CSP-protected pages like "https://github.com", so could you provide a concrete web page URL to show it? Would it better if your Firefox gets updated to 66.0.3?

I've tested on Firefox 66 for Win 10 and Ubuntu 16.

from vimium-c.

The popup page has been fixed in v1.74.3, while the Vomnibar issue is still a mystery.

from vimium-c.

Sorry for the late reply, I was sick last week. I've upgraded to the 1.73.3 version and so far it's fine on one machine (I can't provide a URL since it was an internal resource). I'll report here if I stumble upon any issues though.
Special thanks for the queryInterval option, it's much more snappy now with 100ms delay!

from vimium-c.

Here's another way to debug the Vomnibar issue:

• go to the problematic page
• open the developer tools of Firefox, and click the "network" panel
• reload the page, and then you'll see (many) network requests
• click the earliest "html" item, and at the right panel select "Headers" sub-panel
• (I think) the "Content-Security-Policy" should exist and has something special
  • if it's too long (contains "..."), you may click it the "Raw headers" switch at the top right corner

What I want (now) is only the CSP text and your web page's "host" (something in page's URL that looks like "https://google.com"), so all other info can be masked as you want.

from vimium-c.

I'm not sure whether it's Firefox-specific, but sometimes input box of Vomnibar (shift-O, shift-T) is not focused and I have to click with the mouse to focus the inputbox. I can't reproduce it reliably, but it happened 2-3 times over the past 2 days. After I click the inputbox with the mouse, the focus is correct next time popup appears, so it's rarely reproducable. This is minor but a bit inconvenient when it happens.

from vimium-c.

Yes, it's a possible bug of Vimium.

A Vomnibar is in a different OS process with it's "parent" (host) web page, so there're many race conditions during its initialization. Currently, Vimium C sends a command to show the Vomnibar UI and then waits about 34ms before focusing its input box. In my PC and laptop (Intel i5 / i7...), this logic works well, but it seems no suitable in your case. I'll add more checks.

BTW, in a next time you press Shift+O, Vomnibar will have been inited so it's fast enough to re-show it.

from vimium-c.

Viimium C v1.74.5 has been released. It mainly includes bug fixes, except a new commands performAnotherFind and redesigned Marks.activate supporting extra 8 temporary marks.

The failing-to-focus issue of Vomnibar should be fixed (If not, maybe I'll need to redesign something ...).

The Vomnibar hanging issue on some of your pages may keep existing. You may press <esc> to exit the hanging status. "Content-Security-Policy" of those pages may help debugging.

from vimium-c.

Thank you, @gdh1995!

I'm afraid I'm still observing the missing keyboard focus issue even with the latest release. One page where I've seen it today is https://calendar.google.com. Not consistently, though, but rarely it happens.

As for the hanging issue, it hasn't occurred so far.

from vimium-c.

Hello. Vimium C has released v1.76.6, which adds a feature of auto wrapping around in FindMode.

I think this feature is the last piece of the Firefox's version - now all features not implemented are either too hard or or just impossible on Firefox, compared with the Chrome version.

So you may have a try, and if no new lacking features, I'll close this issue in this weekend.

from vimium-c.

Firefox has a much annoying popup-window blocker and does not trust mouse events from such extensions

Is this still an issue? I noticed that the “follow link” function doesn’t work on some websites under Firefox.

from vimium-c.