Vimium: Existe-t-il un moyen de désactiver Vimium sur ma page en tant que propriétaire de site ?

Créé le 19 janv. 2017 · 27Commentaires · Source: philc/vimium

Excusez-moi si cela est répondu quelque part, mais je ne l'ai pas trouvé dans la FAQ ou le README.

Je dirige un site Web que de nombreux programmeurs utilisent. Certains utilisent Vimium, et il semble que l'extension essaie de mettre à niveau l'édition de certains éléments de ma page. Cela a causé des erreurs JS délicates qui sont très difficiles à localiser ainsi que beaucoup de douleur pour les utilisateurs car ils ne réalisent pas que les échecs sont dus au conflit entre notre code et celui de Vimium.

Existe-t-il un moyen de marquer les éléments avec « si vous utilisez Vimium, veuillez ne pas améliorer cet élément » ? Merci d'avance pour votre réponse.

Source

vincentwoo

👍5 👎1

Commentaire le plus utile

Juste quelques réflexions.

Les webmasters devraient-ils avoir un moyen de désactiver Vimium ?

Avantages : ils peuvent désactiver automatiquement Vimium pour permettre aux utilisateurs d'utiliser immédiatement leurs applications
Inconvénients : les utilisateurs seront confus lorsque les raccourcis ne fonctionneront pas soudainement, cela peut être atténué en informant les utilisateurs que Vimium est désactivé

Les propriétaires de sites Web devraient-ils avoir un moyen de détecter Vimium ?

Avantages : ils peuvent inviter les utilisateurs à expliquer que Vimium pourrait interférer avec les fonctionnalités normales
Inconvénients : cela facilite la prise d'empreintes digitales (mais cela pourrait déjà être une cause perdue)

Je ne sais pas si les webmasters devraient avoir l'une ou l'autre capacité, mais s'ils le font, cela ne devrait probablement pas s'appuyer sur des détails de mise en œuvre fortuits. Une solution standardisée, comme #2532 pourrait être la voie à suivre.

Par exemple, une page peut inclure les éléments suivants :

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

Cela permet au webmaster

Détecter Vimium
Désactiver Vimium

Vimium devrait

laisser l'utilisateur configurer s'il doit
1. ignorer la balise (laisser la page penser que Vimium n'est pas installé)
2. désactiver Vimium en fonction de la propriété disable de meta
rechercher une balise meta et lui envoyer un événement de détection
informer l'utilisateur que la page désactive Vimium

En théorie, d'autres extensions de raccourci clavier peuvent également implémenter cette interface afin que les webmasters n'aient pas à détecter séparément Vimium, cVim, Surfing Keys, Saka Key, VimFx, Vimari, etc.

eejdoowad le 12 juin 2017

👍4

Tous les 27 commentaires

@vincentwoo... Pas actuellement. Une telle fonctionnalité nécessiterait une réflexion approfondie.

smblott-github le 20 janv. 2017

👍1

Êtes-vous prêt à envisager cette fonctionnalité ? Si oui, pouvez-vous dire quelles sont vos principales préoccupations? Je ne veux évidemment pas marcher sur les pieds, mais je veux offrir une meilleure expérience utilisateur à mes utilisateurs qui ont installé Vimium (ce qui est un nombre surprenant de personnes).

vincentwoo le 20 janv. 2017

+1 Ce serait un ajout vraiment utile.

leeny le 24 janv. 2017

Vous pouvez envoyer un faux message unload sur DOM ready/window load - si seul Vimium s'est lancé.

Voici mon exemple : https://jsfiddle.net/2L36ypys/ , et vous verrez que vous ne pouvez pas utiliser f pour activer les astuces.

Cela fonctionne depuis le commit adce73cb68f7ca3e3e01ca6fbb08a1008c9c8b90 (2016/04/05).

BTW, pourriez-vous fournir plus d'indices et nous pouvons résoudre de tels conflits.

gdh1995 le 25 janv. 2017

Je ne suis pas moi-même un utilisateur de vimium, donc je l'installerai demain et j'essaierai d'avoir un rapport de bogue plus concret pour vous. Merci pour l'extrait.

vincentwoo le 25 janv. 2017

En fait, selon les tests dans https://jsfiddle.net/2L36ypys/1/ , nous pouvons envoyer un tel message depuis l'environnement "host" lorsque la page est "loading" , car Vimium installe son unload écouteur d'événement avant tous les autres scripts de page.

Mais mon Vimium++ n'utilise pas cet écouteur et il n'y a pas de méthode simple pour le détruire par des scripts de page.

J'attends donc vos recherches. Une page de test où vous pouvez reproduire les erreurs est tout simplement OK. Merci beaucoup.

gdh1995 le 25 janv. 2017

En lien avec cela, il existe un projet vieux de 2 ans pour détecter si l'utilisateur utilise Vimium, pourrait être utile ici : https://github.com/EvanHahn/Detect-Vimium

pimlottc le 5 avr. 2017

@pimlottc L'extension n'a pas fonctionné depuis 1 ou 2 ans, car Vimium utilise 'shadowDOM' pour masquer ses nœuds.

gdh1995 le 6 avr. 2017

Je n'ai pas pu reproduire exactement le problème que les utilisateurs de vimium ont sur mon site (probablement parce que je n'utilise pas Vim personnellement). Est-il toujours sur la table d'ajouter une sorte de classe CSS spécifique à vimium aux éléments pour demander à l'extension de ne pas l'augmenter ?

vincentwoo le 6 avr. 2017

Est-il toujours sur la table d'ajouter une sorte de classe CSS spécifique à vimium aux éléments pour demander à l'extension de ne pas l'augmenter ?

Je ne suis pas sûr que ce soit une bonne idée.

Bien sûr, cela entraînerait une confusion chez les utilisateurs si Vimium ne fonctionnait pas du tout sur certains sites, et les utilisateurs peuvent déjà désactiver eux-mêmes Vimium sur votre site, voir ici .

De plus, si nous poursuivons votre idée, nous aurions probablement également besoin d'un mécanisme permettant aux utilisateurs de réactiver Vimium.

smblott-github le 6 avr. 2017

👍1

Bien. Y a-t-il un moyen pour nous de savoir au moins si Vimium a été activé ? Le problème est que les utilisateurs nous blâment lorsqu'une chose se brise en raison d'une interaction étrange. Mon service utilise déjà une surface d'édition très compliquée (CodeMirror), donc j'aimerais pouvoir faire quelque chose .

vincentwoo le 6 avr. 2017

Si Vimium pouvait au moins ajouter un artefact sur le DOM d'une manière ou d'une autre, au moins des sites comme celui auquel @vincentwoo fait référence pourraient être _sensibilisés_ à l'installation de Vimium par l'utilisateur et ils pourraient afficher un message à l'utilisateur lui rappelant qu'il pourrait y avoir des comportements conflictuels lorsque vous combinez une interface utilisateur complexe dans la page Web avec toutes les offres Vimium, ou même offrez de l'aide pour configurer l'application en question ou Vimium pour les résoudre.

rtlong le 30 mai 2017

Si Vimium pouvait au moins ajouter un artefact sur le DOM d'une manière ou d'une autre...

Nous préchargeons le Vomnibar sur chaque page (de niveau supérieur). Nous pourrions lui attribuer une classe ou un identifiant approprié, je suppose.

smblott-github le 30 mai 2017

Cela aiderait certainement!

vincentwoo le 30 mai 2017

@smblott-github Mon idée est que Vimium renomme son nœud hôte fantôme de <div> en un autre nom, comme <vimium-ui> , puis il suffit de rechercher les enfants de <html> pour ce nom de balise. Je pense que ce nom de balise d'élément personnalisé ne sera pas le même que celui d'autres sites Web.

gdh1995 le 30 mai 2017

Mon idée est que Vimium renomme son nœud hôte fantôme de <div> en un autre nom, comme <vimium-ui> , puis il suffit de rechercher les enfants de <html> pour ce nom de balise .

Ce n'est actuellement pas possible à cause de ce problème de chrome .

Vous pourriez détecter nos ressources accessibles sur le Web. Par exemple:

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 le 30 mai 2017

👍1

@ mrmr1993 Je ne veux pas créer un élément « personnalisé », juste un HTMLElement avec un nom de balise personnalisé. Un nœud HTMLElement est comme un HTMLUnknownElement mais prend toujours en charge l'attachement d'un shadowRoot.

gdh1995 le 31 mai 2017

Juste quelques réflexions.

Les webmasters devraient-ils avoir un moyen de désactiver Vimium ?

Avantages : ils peuvent désactiver automatiquement Vimium pour permettre aux utilisateurs d'utiliser immédiatement leurs applications
Inconvénients : les utilisateurs seront confus lorsque les raccourcis ne fonctionneront pas soudainement, cela peut être atténué en informant les utilisateurs que Vimium est désactivé

Les propriétaires de sites Web devraient-ils avoir un moyen de détecter Vimium ?

Avantages : ils peuvent inviter les utilisateurs à expliquer que Vimium pourrait interférer avec les fonctionnalités normales
Inconvénients : cela facilite la prise d'empreintes digitales (mais cela pourrait déjà être une cause perdue)

Par exemple, une page peut inclure les éléments suivants :

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

Cela permet au webmaster

Détecter Vimium
Désactiver Vimium

Vimium devrait

laisser l'utilisateur configurer s'il doit
1. ignorer la balise (laisser la page penser que Vimium n'est pas installé)
2. désactiver Vimium en fonction de la propriété disable de meta
rechercher une balise meta et lui envoyer un événement de détection
informer l'utilisateur que la page désactive Vimium

eejdoowad le 12 juin 2017

👍4

Moi aussi je cherche une solution pour détecter le vimium. La proposition de @eejdoowad a fière allure. En attendant, je suis d'accord avec @gdh1995 , un <div> avec un identifiant/nom de classe particulier résoudra immédiatement le problème pour le moment.

À partir de vimium v1.59, vous trouverez ci-dessous une fonction de travail, pas entièrement fiable cependant, en raison du manque d'identifiant fiable, si vous avez d'autres extensions qui insèrent shadowDom comme le fait vimium, cela se brisera.

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

hackape le 29 juin 2017

Je voudrais juste dire que je serais inquiet si un mécanisme de détection intégré était mis en œuvre. La prise d'empreintes digitales peut bien sûr toujours être effectuée avec des plugins qui changent le DOM à moins que l'on interdise le javascript du site Web, mais au moins ne donnons pas aux gens une cible de point de données facile à suivre...

lindhe le 16 août 2017

Nous pourrions avoir un mécanisme où nous ne détectons pas Vimium, mais ajoutons, disons, une balise meta sur notre page qui a un message à afficher juste au cas où un utilisateur Vimium utilise la page, avec la possibilité de désactiver. Vimium peut ainsi éviter les détections triviales et nous n'apprenons pas nécessairement quoi que ce soit sur l'utilisateur.

vincentwoo le 17 août 2017

👍2

C'est tout à fait nécessaire pour l'application sur laquelle je travaille à cause de bogues comme https://github.com/philc/vimium/issues/2504 . Le résumé est qu'avec l'exécution de vimium, le site Web commencera par être réactif et deviendra de plus en plus lent à mesure que les gestionnaires d'événements s'empilent.

Ce serait bien que les sites Web puissent détecter :

Quelle version de vimium est utilisée
Si vimium est activé / désactivé / partiellement désactivé (et quelles touches).

Et ce serait bien si le site Web pouvait poliment désactiver vimium d'une manière claire pour les utilisateurs (de telle sorte que l'icône de vimium ne soit plus bleue)

mgsloan le 5 janv. 2018

@mgsloan Pouvez-vous fournir un exemple de page, s'il vous plaît ? La façon dont le mode d'insertion est géré a considérablement changé depuis #2504.

(Je ne suis pas sûr que les sites désactivent unilatéralement Vimium. Cela pourrait être assez déroutant.)

smblott-github le 5 janv. 2018

@smblott-github Bonjour, merci pour la réponse ! En effet, le problème de performance semble avoir disparu. Super!

Il y a un problème où certains comportements d'entrée sont assez différents de ceux lorsque vimium est désactivé. Je vais me renseigner et voir si nous pouvons partager l'url.

mgsloan le 11 janv. 2018

Salut! Y a-t-il une idée des approches qui pourraient être acceptables pour les responsables du projet ? Nous serions prêts à donner du temps pour y parvenir (beaucoup d'utilisateurs de vimium utilisent CoderPad) mais nous ne voulons pas marcher sur les pieds.

vincentwoo le 19 mars 2019

Je pense que le point clé attendu par Vimium est que tous les utilisateurs l'utilisent sans aucune douleur ni ennui.

Étant donné que votre site a des actions spéciales qui sont différentes avec Vimium, y compris esc sur les zones de saisie, Vimium devrait-il autoriser « exclure » <esc> sur sa page d'options ?

Si c'est le cas, vos utilisateurs peuvent le configurer manuellement et récupérer les actions du site (actuellement, il semble que <esc> ne puisse pas être exclu).

Mais je n'aime pas l'idée que Vimium se désactive en répondant à des conditions spéciales. Cela nuit à la valeur de Vimium.

Quant à la publication de la version de Vimium, je conseille :

un chemin de ressource accessible sur le Web contenant la chaîne de version de Vimium
- plus correct, mais pas adapté aux différentes variantes de Vimium
- par exemple, je fais un "Vimium C", et il a un ID d'extension différent, et donc des URL de ressources différentes)
ou un tag spécial <meta> , créé par Vimium et contenant des mots comme "Vimium"
- plus facile à vérifier, mais peut être abusé par des malwares

gdh1995 le 20 mars 2019

La vérification de la div de niveau supérieur ne semble plus fonctionner car elle n'est plus montée tant que l'utilisateur n'a pas fait quelque chose.

En d'autres termes, au chargement de la page, il n'y a pas d'artefact sur lequel s'appuyer