3 ms·

> Vimium these days does not work when a page hasn't finished loading and it doesn't work on blank pages (about:blank) or any other "system page" (like the pref

> Vimium these days does not work when a page hasn't finished loading and it doesn't work on blank pages (about:blank) or any other "system page" (like the preferences or addons). While the new limitations in WebExtensions can be limiting, these in particular don't sound insurmountable. Firstly, while I haven't looked into Vimium's sourcecode (yet) there's no reason in my mind it shouldn't work while page is loading. Unless there's some Firefox bugs (VERY possible), the manifest `run-at: document-start` enables this. Other extensions make ample use of run-at and it has worked perfectly in my experience: things like Violentmonkey even expose it via their own API in the form of `@run-at` metadata and I haven't experienced any delays triggering that. System pages are disabled by default but I believe there's an option either in Firefox prefs or in about:config to re-enable them. Inconvenient but not insurmountable.

mikae1 5y ago
> While the new limitations in WebExtensions can be limiting, these in particular don't sound insurmountable. That sounds promising, but I haven't seen anybody solve it with WebExtensions yet. Just tried Vimium in Chromium too. Same problems. The end user experience is worse than the picture I painted as my list of drawbacks was incomplete. Here's another one... Say the server is offline or you mistyped a URL and you get to the "Hmm. We’re having trouble finding that site." page. You're stuck as your vim shortcuts don't work anymore. It's like a friend that should just be there, but can't be trusted.
- lucideer 5y ago
  The "Hmm. We’re having trouble finding that site." page is considered one of the internal protected pages, so in theory toggling the appropriate setting to allow extensions on those pages should fix that issue. Just for clarity, those "special" internal pages in the browser have privileged access to some specific user data, so the intent of having extensions off-by-default on them is to ensure extensions don't all have full access to all that data by default. However, this seems similar to extensions being disabled by default in Private Windows, which is easy to toggle, so I really wish they'd make special browser pages as easy to toggle.

mikae1 5y ago

> While the new limitations in WebExtensions can be limiting, these in particular don't sound insurmountable. That sounds promising, but I haven't seen anybody solve it with WebExtensions yet. Just tried Vimium in Chromium too. Same problems. The end user experience is worse than the picture I painted as my list of drawbacks was incomplete. Here's another one... Say the server is offline or you mistyped a URL and you get to the "Hmm. We’re having trouble finding that site." page. You're stuck as your vim shortcuts don't work anymore. It's like a friend that should just be there, but can't be trusted.

lucideer 5y ago
The "Hmm. We’re having trouble finding that site." page is considered one of the internal protected pages, so in theory toggling the appropriate setting to allow extensions on those pages should fix that issue. Just for clarity, those "special" internal pages in the browser have privileged access to some specific user data, so the intent of having extensions off-by-default on them is to ensure extensions don't all have full access to all that data by default. However, this seems similar to extensions being disabled by default in Private Windows, which is easy to toggle, so I really wish they'd make special browser pages as easy to toggle.