menus.ContextType editable does not match a <selection> (dropdown)

Hi I am writing an extension that allows password and other data to be entered on input fields, by picking a context menu option created with contexts: [“editable”].
This works fine for input fields, but the menu option does not appear when right clicking on a field.
Thus I seem to have to use contexts: [“all”] which means the menu also appears when clicking on a non input capable element which is confusing.

I seem to recall that this once worked (some years back) - is this an oversight or am I missing something?

Thanks

1 Like

In the docs compatibility it’s written that:

'The ‘editable’ context does not include password fields. Use the ‘password’ context for this.

<select>s aren’t password fields though…

1 Like

Yeah, I’m not a very sharp reader :smiley:. Who is reading a heading? LOL!

Also his question was a bit vague, it really “felt” like he is asking for password field (and just forget the word “password”).

Anyway, so select doesn’t count as editable, which makes sense I guess…

[quote="juraj.masiar, post:4, topic:84584]
Anyway, so select doesn’t count as editable, which makes sense I guess…
[/quote]

I disagree - a .
Thus I am forced to use contexts: [“all”] which means the menu also appears when clicking on a non input capable element. This looks weird and I cannot see an other way to avoid it.

Maybe you can try to modify the page elements into something you can match?

Out of box idea - setting contenteditable to true on those select boxes :slight_smile:.

BTW, how does it behave in other browsers?

the editable context is for areas where text is editable, so where the execCommand features work etc. That is how the web generally treats “editable”.

You can hide/show the item during menus.onShown - Mozilla | MDN

1 Like

[quote="freaktechnik, post:7, topic:84584]
You can hide/show the item during menus.onShown - Mozilla | MDN
[/quote]
I did not notice that possibility and will give that a go
Thank you