Vimium: Is there a way to disable Vimium on my page as a site owner?

Created on 19 Jan 2017 · 27Comments · Source: philc/vimium

Pardon me if this is answered somewhere, but I couldn't find it in the FAQ or README.

I run a website that many programmers use. Some of the use Vimium, and it appears the extension tries to upgrade editing on certain elements on my page. This has been causing some tricky JS errors that are very hard to track down as well as a lot of user pain because they don't realize the failures are due to the conflict between our code and Vimium's.

Is there a way to tag elements with "if you are running Vimium, please do not enhance this element"? Thanks for your reply in advance.

Source

vincentwoo

👍5 👎1

Most helpful comment

Just a few thoughts.

Should webmasters have a way to disable Vimium?

Pros: they can disable Vimium automatically to let users immediately use their apps
Cons: users will be confused when shortcuts suddenly don't work, this can be mitigated by informing users that Vimium is disabled

Should website owners have a way to detect Vimium?

Pros: they can prompt users to explain that Vimium might interfere with normal functionality
Cons: this facilitates fingerprinting (but this might already be a lost cause)

I'm not sure if webmasters should have either ability, but if they do, it probably shouldn't rely on coincidental implementation details. A standardized solution, like #2532 might be the way to go.

For example, a page might include the following:

<meta name="keybinding" disable="suggest")">
<script>
  document.querySelector('meta[name="keybinding"]').addEventListener('detect', () => {
    console.log('hi vimium user');
  });
</script>

This lets the webmaster

Detect Vimium
Disable Vimium

Vimium would have to

let the user configure whether to
1. ignore the tag (letting the page think Vimium isn't installed)
2. disable Vimium based on meta's disable property
check for a meta tag and dispatch a detection event to it
inform the user that the page is disabling Vimium

In theory, other keybinding extensions can also implement this interface so web masters won't have to detect Vimium, cVim, Surfing Keys, Saka Key, VimFx, Vimari, etc. separately.

eejdoowad on 12 Jun 2017

👍4

All 27 comments

@vincentwoo... Not currently. Such a feature would require some careful thought.

smblott-github on 20 Jan 2017

👍1

Are you open to considering this feature? If so, can you say what some of your major concerns are? I obviously don't want to step on any toes, but I do want to offer a better user experience for my users who have Vimium installed (which is a surprising chunk of people).

vincentwoo on 20 Jan 2017

+1 This would be a really useful addition.

leeny on 24 Jan 2017

You may dispatch a fake unload message on DOM ready / window load - if only Vimium has inited.

Here's my example: https://jsfiddle.net/2L36ypys/, and you'll see you can not use f to activate hints.

This works since commit adce73cb68f7ca3e3e01ca6fbb08a1008c9c8b90 (2016/04/05).

BTW, could you provide more clues and we may solve such conflicts.

gdh1995 on 25 Jan 2017

I'm not a vimium user myself, so I'll install it tomorrow and try to have a more concrete bug report for you. Thanks for the snippet.

vincentwoo on 25 Jan 2017

In fact, according to tests in https://jsfiddle.net/2L36ypys/1/, we can dispatch such a message from the "host" environment when the page is "loading", because Vimium installs its unload event listener before all other page scripts.

But my Vimium++ does not use this listener and there's no easy method to destroy it by page scripts.

So I'm expecting your searches. A test page where you can reproduce errors is just OKay. Thanks a lot.

gdh1995 on 25 Jan 2017

Related to this, there is a 2-year old project to detect whether the user is using Vimium, might be useful here: https://github.com/EvanHahn/Detect-Vimium

pimlottc on 5 Apr 2017

@pimlottc The extension has not worked for 1 or 2 years, because Vimium uses 'shadowDOM' to hide its nodes.

gdh1995 on 6 Apr 2017

I could not exactly reproduce the problem that vimium users have on my site (probably because I don't use Vim personally). Is it still on the table to add some kind of vimium-specific CSS class to elements to ask the extension not to augment it?

vincentwoo on 6 Apr 2017

Is it still on the table to add some kind of vimium-specific CSS class to elements to ask the extension not to augment it?

I'm not sure this is a great idea.

For sure it would cause user confusion if Vimium just didn't work at all on some sites, and users can already disable Vimium on your site themselves, see here.

Also, if we pursued your idea then we'd probably also need a mechanism for users to re-enable Vimium.

smblott-github on 6 Apr 2017

👍1

Alright. Is there a way for us to at least know if Vimium has been enabled? The issue is users blame us when a thing breaks due to a strange interaction. My service already uses a very complicated editing surface (CodeMirror), so I'd like to be able to do something.

vincentwoo on 6 Apr 2017

If Vimium could at least add an artifact on the DOM in some way, at least sites like @vincentwoo's referring to could be _made aware_ the user has Vimium installed and they could show a message to the user reminding them there might be conflicting behaviors when combining a complex UI in the webpage with all the Vimium offers, or even offer help in configuring either the app in question or Vimium to resolve them.

rtlong on 30 May 2017

If Vimium could at least add an artifact on the DOM in some way...

We pre-load the Vomnibar on every (top-level) page. We could assign it a suitable class or id, I guess.

smblott-github on 30 May 2017

That would certainly help!

vincentwoo on 30 May 2017

@smblott-github My idea is that Vimium renames its shadow host node from <div> to another name, like <vimium-ui>, and then it is just enough to search <html>'s children for this tag name. I think this custom-element tag name won't happen to be the same as other websites'.

gdh1995 on 30 May 2017

My idea is that Vimium renames its shadow host node from <div> to another name, like <vimium-ui>, and then it is just enough to search <html>'s children for this tag name.

This currently isn't possible because of this Chromium issue.

You could detect our web-accessible resources. For example:

var xhr = new XMLHttpRequest(),
    vimiumEnabled = false;
xhr.onerror = xhr.onload = function(){vimiumEnabled = xhr.responseText !== "";};
xhr.open("GET","chrome-extension://dbepggeogbaibhgnhhndojpepiihcmeb/content_scripts/vimium.css");
xhr.send()

mrmr1993 on 30 May 2017

👍1

@mrmr1993 I don't want to create a “custom” element, just a HTMLElement with a custom tag name. A HTMLElement node is just like a HTMLUnknownElement but still supports to attach a shadowRoot.

gdh1995 on 31 May 2017

Just a few thoughts.

Should webmasters have a way to disable Vimium?

Pros: they can disable Vimium automatically to let users immediately use their apps
Cons: users will be confused when shortcuts suddenly don't work, this can be mitigated by informing users that Vimium is disabled

Should website owners have a way to detect Vimium?

Pros: they can prompt users to explain that Vimium might interfere with normal functionality
Cons: this facilitates fingerprinting (but this might already be a lost cause)

I'm not sure if webmasters should have either ability, but if they do, it probably shouldn't rely on coincidental implementation details. A standardized solution, like #2532 might be the way to go.

For example, a page might include the following:

<meta name="keybinding" disable="suggest")">
<script>
  document.querySelector('meta[name="keybinding"]').addEventListener('detect', () => {
    console.log('hi vimium user');
  });
</script>

This lets the webmaster

Detect Vimium
Disable Vimium

Vimium would have to

let the user configure whether to
1. ignore the tag (letting the page think Vimium isn't installed)
2. disable Vimium based on meta's disable property
check for a meta tag and dispatch a detection event to it
inform the user that the page is disabling Vimium

In theory, other keybinding extensions can also implement this interface so web masters won't have to detect Vimium, cVim, Surfing Keys, Saka Key, VimFx, Vimari, etc. separately.

eejdoowad on 12 Jun 2017

👍4

Me too search for a solution to detect vimium. @eejdoowad's proposal looks great. Meanwhile I agree with @gdh1995, a <div> with a peculiar id/classname will immediately solve the problem for now.

As of vimium v1.59, below's a working function, Not entire reliable though, due to lack of a reliable identifier, if you have other extensions that insert shadowDom the way vimium does then it'll break.

function hasVimium () {
  try {
    const shadowRoot = document.querySelector('html > div').shadowRoot;
    return Boolean(shadowRoot.querySelector('style').textContent.match(/vimium/));
  } catch (e) {
    return false;
  }
}

hackape on 29 Jun 2017

I'd just like to pitch in saying that I would be concerned if a built in detection mechanism was implemented. Fingerprinting can of course always be done with plugins that are changing DOM unless one would prohibit website javascript, but let's at least not give people an easy data point target to track...

lindhe on 16 Aug 2017

We could have a mechanism where we don't detect Vimium, but add, say, a meta tag on our page that has a message to display just in case a Vimium user happens to be using the page, with the option to disable. Vimium thus can avoid trivial detection and we don't necessarily learn anything about the user.

vincentwoo on 17 Aug 2017

👍2

This is quite necessary for the application I work on because of bugs like https://github.com/philc/vimium/issues/2504 . Summary is that with vimium running, the website will start out responsive, and get slower and slower as event handlers stack up.

It would be nice of websites could detect:

Which vimium version is being used
Whether vimium is enabled / disabled / partially disabled (and which keys).

And would be nice if the website could politely disable vimium in a way that is clear to users (such that the vimium icon is no longer blue)

mgsloan on 5 Jan 2018

@mgsloan Can you provide an example page, please? The way insert mode is handled has changed substantially since #2504.

(I'm not sure about sites unilaterally disabling Vimium. That could be quite confusing.)

smblott-github on 5 Jan 2018

@smblott-github Hi, thanks for the response! Indeed the performance issue seems to be gone. Great!

There is an issue where some input behavior is quite a bit different than when vimium is disabled. I'll inquire and see if we can share the url.

mgsloan on 11 Jan 2018

Hi there! Is there some sense of which approaches might be acceptable to the project maintainers? We would be willing to donate some time to get this done (quite a few vimium users use CoderPad) but don't want to step on any toes.

vincentwoo on 19 Mar 2019

I think the keypoint expected by Vimium is that all users use it without any pain or annoyance.

Since your site has some special actions which are different with Vimium, including esc on input boxes, should Vimium allow to "exclude" <esc> on its options page?

If so, your users may configure it manually and get site's actions back (currently, it seems that <esc> can not be excluded).

But I don't like the idea of Vimium disabling itself on meeting special conditions. It's a harm to Vimium's value.

As for publishing the version of Vimium, I advice:

a web-accessible resource path containing Vimium's version string
- more correct, but not suitable for different variants of Vimium
- for example, I make a "Vimium C", and it has a different extension ID, and so different resource URLs)
or a special <meta> tag, created by Vimium and containing some words like "Vimium"
- easier to check, but may be abused by malwares