Vimium's detection of text entry forms

[tjhowse]

Very rarely I click on an input box or other text entry field and start typing, only to have Vimium catch the keystrokes rather than the text going into the field. Is there some general advice I could supply to a web developer to avoid this behaviour? I have to assume it's because of some slightly off-piste deb development. An example of such behaviour can be found in the comment box on articles on jank dot cool.

To be clear: Vimium behaves as expected in 99.95% of cases. It's just the occasional weird website that trips it up.

[philg-dev]

Well, it's borderline impossible to tell what's going on if there's no proper example to look at.

The example you've stated requires an account.

If you're not at all familiar with any degree of web development yourself, then it's really hard to give any pointers just based on your description.

What you could try is, to inspect the comment box with your browser tools and provide a snippet of the surrounding HTML code.

There is a "permanent Insert Mode" lurking under the hood, that prevents Normal Mode keybindings from being triggered when a the page's active element is "focusable" according to Vimium's dom_utils function linked below:

vimium/lib/dom_utils.js

Lines 279 to 281 in 5aa2961

	isFocusable(element) {
	return element && (this.isEditable(element) || this.isEmbed(element));
	},

Which is true when at least one of these functions returns true (and the given element is truthy, of course):

vimium/lib/dom_utils.js

Lines 265 to 277 in 5aa2961

	// Input or text elements are considered focusable and able to receieve their own keyboard events,
	// and will enter insert mode if focused. Also note that the "contentEditable" attribute can be
	// set on any element which makes it a rich text editor, like the notes on jjot.com.
	isEditable(element) {
	return (this.isSelectable(element)) ||
	((element.nodeName != null ? element.nodeName.toLowerCase() : undefined) === "select");
	},
	// Embedded elements like Flash and quicktime players can obtain focus.
	isEmbed(element) {
	const nodeName = element.nodeName != null ? element.nodeName.toLowerCase() : null;
	return ["embed", "object"].includes(nodeName);
	},

Where isEditable() calls this function:

vimium/lib/dom_utils.js

Lines 239 to 263 in 5aa2961

	// Selectable means that we should use the simulateSelect method to activate the element instead
	// of a click.
	//
	// The html5 input types that should use simulateSelect are:
	// ["date", "datetime", "datetime-local", "email", "month", "number", "password", "range",
	// "search", "tel", "text", "time", "url", "week"]
	// An unknown type will be treated the same as "text", in the same way that the browser does.
	//
	isSelectable(element) {
	if (!(element instanceof Element)) return false;
	const unselectableTypes = [
	"button",
	"checkbox",
	"color",
	"file",
	"hidden",
	"image",
	"radio",
	"reset",
	"submit",
	];
	return ((element.nodeName.toLowerCase() === "input") &&
	(unselectableTypes.indexOf(element.type) === -1)) ||
	(element.nodeName.toLowerCase() === "textarea") || element.isContentEditable;
	},

So the most relevant part for when Vimium properly automatically enters Insert Mode is the check for certain types of HTML <input> elements.

As an example, when you look at en.wikipedia.org and inspect the text input field for the search, can see it's an <input type='search'>. The type='search' is not contained in the list of exceptions in the isSelectable() function, thus the automatic Input Mode passes all key events to the underlying page instead of bubbling the event up to Vimium's Normal Mode key handling.

I hope this at least somewhat makes sense... Since I'm not sure what your background with software development stuff is, it might be a bit too technical already. But yeah, if you know a web developer that you want to refer this comment to, feel free to do so.

[tjhowse]

Thanks for the detailed response. I'm a software engineer, but not a front-end guy beyond a bare minimum. The comments functionality appears to be provided by https://github.com/RooCodeInc/sample-ghost/tree/main/apps/comments-ui

The comment field is as follows. I have drafted a comment in this example.

<form data-testid="form">
    <div class="min-h-[120px] w-full rounded-lg border border-black/10 bg-white/75 p-2 pb-[68px] font-sans text-md leading-normal transition-all delay-100 duration-150 focus:outline-0 dark:bg-white/10 dark:text-neutral-300 sm:px-3 sm:text-lg cursor-text"
        data-testid="form-editor">
        <div>
            <div data-testid="editor" translate="no" class="tiptap ProseMirror gh-comment-content focus:outline-0"
                tabindex="0" contenteditable="true">
                <p>This is a comment I have typed after manually entering insert mode.</p>
            </div>
        </div>
    </div>
    <div class="absolute bottom-1 right-1 flex space-x-4 transition-[opacity] duration-150 sm:bottom-2 sm:right-2">
        <button
            class="flex w-auto items-center justify-center false false h-[40px] rounded-md bg-[var(--gh-accent-color)] px-3 py-2 text-center font-sans text-base font-medium text-white outline-0 transition-colors duration-200 hover:brightness-105 disabled:bg-black/5 disabled:text-neutral-900/30 dark:disabled:bg-white/15 dark:disabled:text-white/35 sm:text-sm"
            data-testid="submit-form-button" type="button"><span><span class="hidden sm:inline">Add comment </span><span
                    class="sm:hidden">Comment</span></span></button></div>
</form>

The parent div of the p has contenteditable="true" set, but I'm guessing the keystrokes are handled by some script nonsense that masks that.

Cheers,
tjhowse.

[philg-dev]

Well the problem with the contenteditable attribute is, that it's not being checked by Vimium's isEditable() function, which is very counter-intuitive. The isSelectable function checks for that attribute, but only under the "precondition" that the active element is an HTML <input> to begin with. In the code snippet you provided it definitely looks like there's no <input> element in that particular structure. (Some insane web developers could still manage to have a corresponding <input> element in a completely different place, going against everything that might be considered "best practice". I came across an example like that at some point, but forgot where it was.) Edit: I missed a parenthesis in the condition block... the element should properly be checked for the isContentEditable attribute, however in your case it seems like the active element is not what we would expect. Sorry for the confusion.

This is probably a fairly "fragile" piece of the logic in Vimium, as these functions from dom_utils.js are used in a bunch of different places in the codebase. Therefore I'm not sure if it was intentionally implemented that way, if it's just an oversight or maybe a mix of both.

I think it would be valuable, if you could find out what the active element is on your affected website. In the browser tools in the debugger section you should be able to find the file tree of all the source files used in the active page. You should be able to find Vimium/lib/dom_utils.js and there you can just set a breakpoint in the isFocusable function. It might be a bit tricky to find exactly what you need, since this function is very "trigger happy". So you'll probably have to click directly into the comment field of the page after setting up the breakpoint in the dev tools - clicking anywhere else will immediately put you back to the debugger.

Alternatively, it might actually be easier to use a conditional breakpoint and set the condition to element.isContentEditable. (Edit: you can set a breakpoint condition by right-clicking on the line number in the debugger.) That should hopefully catch it on your example page. Edit: you can get the element's HTML code by putting element.outerHTML in the browser console, while the site is paused on that breakpoint.

That breakpoint condition does not catch it for the GitHub comment box, which is a nice anecdote as for why this stuff is so messy to detect by a third party add-on like Vimium. But obviously the GitHub comment box meets different criteria that Vimium recognizes.