Shadow DOM problem/suggestion

[samvasko]

Hi!
I am currently finishing porting my extension to use Shadow DOM. I was wrestling with the same issue like vimium, where css of page I was injecting into has been modifying css of the extension. Shadow DOM separates extension from other styles, Very neat.

But when I have Input element inside of #documet-fragment vimium still reacts to typing like I am not in input.
Example on JsBin

if you want to check my extension. It is in Slovak, but code is in English.

[JoelBesada]

I ran into this same issue on an extension I'm developing using the Shadow DOM. Since Vimium uses document.activeElement, which points to the Shadow DOM root element and not the actual element inside, it cannot see that the user is actually typing into an input element.

I managed to work around this by adding the contenteditable attribute to the Shadow DOM root element, which marks it as an input element. It would be great however if there was some other Vimium specific class or property that could be set on the Shadow DOM root to mark it as an input element.

[philc]

Interesting, thanks for the research guys. So is the contract change you're proposing is that vimium support a pre-defined, special classname to mark a node as editable? What parts of vimium would need to support that?

[mrmr1993]

The example above no longer works now Element.webkitCreateShadowRoot has been depreciated. Updated example here.

We can detect that an element has a shadow root by checking that element.shadowRoot != null, and further can capture focus events after one fires on the shadow root with element.shadowRoot.addEventListener("focus", listener, true). Tying this together, we should be able to activate input mode for shadow DOM elements to kill this bug.

[mrmr1993]

This was fixed by #1627.