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

vincentwoo commented 7 years ago

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 commented 7 years ago

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

vincentwoo commented 7 years ago

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 commented 7 years ago

+1 This would be a really useful addition.

gdh1995 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

vincentwoo commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

That would certainly help!

gdh1995 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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)

smblott-github commented 6 years ago

@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 commented 6 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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

rddunphy commented 3 years ago

It would be great if there was some sort of standard for websites to communicate key bindings. Then, e.g. a website that uses WASD as controls for a game could include something like:

<meta name="keybindings" value="w,a,s,d">

On loading the page, Vimium could then do one of the following (ideally, the behaviour would be configurable in the Vimium options page):

Warn the user
Disable Vimium for the page
Enter insert mode (but this one would probably be confusing for users)
Automatically add a rule to disable only the required keys for the page

alanhe421 commented 1 year ago

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

safari/edge not work.

Edge has CORS issue Safari not support

philc / vimium

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