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

[vincentwoo]

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.

[smblott-github]

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

[vincentwoo]

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).

[leeny]

+1 This would be a really useful addition.

[gdh1995]

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.

[vincentwoo]

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.

[gdh1995]

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.

[pimlottc]

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

[gdh1995]

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

[vincentwoo]

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?

[smblott-github]

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.

[vincentwoo]

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.

[rtlong]

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.

[smblott-github]

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.

[vincentwoo]

That would certainly help!

[gdh1995]

@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'.

[mrmr1993]

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()

[gdh1995]

@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.

[eejdoowad]

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.

[hackape]

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;
  }
}

[lindhe]

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...

[vincentwoo]

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.

[mgsloan]

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:

1. Which vimium version is being used
2. 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)

[smblott-github]

@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.)

[mgsloan]

@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.

[vincentwoo]

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.

[gdh1995]

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
  
  

[thien-do]

Checking the top-level div doesn't seem to work anymore because it's no longer mounted until the user does something.

In other words, on page load, there is no artifact to rely on