~theclapp You're right that I can get focus back with shift-tab. I indeed had not tried that, expecting focus to cycle back with enough presses of tab. :D

However, the core issue is that using a naked key.InputOp for shortcut handling doesn't work in WASM unless you either tab to focus it or create an editor. I think this is either a bug or a really unfortunate behavior difference.

After pressing tab again, I have found no way to make keypresses register again

Just to check: You've tried shift-tab, yes?

That's an odd behaviour

It was, and it was totally user error. My apologies.

The keys I was listening for were shortcuts for items in a list. I built the list of keys to listen for during layout of the list. But of course I set the InputOp at the top of the layout, before I'd build the list of keys to listen for, so in some circumstances I'd listen for "" and so, yeah, the keyboard events were not what I expected! But after the first layout, the list of keys had been set correctly, so the InputOp was then properly configured.

The mouse pointer position thing had to do with whether the mouse was inside a widget that cared about mouse position (which given how I was exercising this feature was pretty often), and would thus cause an extra redraw, so then, again, the list of keys to listen for had been set correctly.

Again, my apologies!

So sometimes I listen for unmodified keys (e.g. key.Set("A|B|C")), and sometimes instead of a keydown key.Event when I press the A key, I get

key.EditEvent{Range:key.Range{Start:0, End:0}, Text:"a"}
key.SelectionEvent{Start:1, End:1}
key.Event{Name:"A", Modifiers:0x0, State:0x1} // <- key UP key.Event

The key.SelectionEvent comes from SetEditorSelection which comes from gio_insertText, which is as far back as I've traced it. Not sure what else is going on.

Weirdly this seems to depend on where my mouse pointer is with respect to some other widgets I'm drawing. If it's inside certain widgets' bounding box, I get the regular key up & down events; if it's outside them, I get the behavior described above.

If I press A again, I get the regular key down event.

Oh, no, nevermind, I see that key.Event events are fine. Sorry.

Is this bit problematic?

https://git.sr.ht/~eliasnaur/gio/tree/2381c5ad70b2d64042422177bc227d8e2a085201/item/io/router/router.go#L159

		case key.EditEvent, key.FocusEvent, key.SelectionEvent:
			if f := q.key.queue.focus; f != nil {
				q.handlers.Add(f, e)
			}

I don't understand everything going on here, but not queueing the event if nothing is focussed seems bad.

I've seen this in my own app. e.g. if I have an InputOp listening for hotkeys, and an editor lower down (or higher up, depending on how you look at it), all is well. But if in the next frame I then don't layout the editor for some reason, then no widget has focus, and in that case no InputOp widgets anywhere get any keys. I solved it by focusing the top-level InputOp when I stopped laying out the editor. But if the system did that for me automatically that would be grand. :)

Both fixed in latest commit.

Thanks!

The Set listens for Short or Shift (both optional), but the code looks for ShortcutAlt or "no modifiers".

Did you quote the right bit? That bit referred to the delete keys, which you said you fixed. Perhaps you meant "Also if the Editor is Submit:false, then it shouldn't listen for return/enter"?

I see InputOp.Keys as a static property, describing the complete set of possible shortcuts and not a dynamic set describing what it can handle at any given time. Perhaps you have a use-case where a dynamic set is necessary?

I'll grant you the Short-[C-X] is arguable.

The bit about skip up/down/page-up/page-down for single-line widgets and skip enter/return for non-submit widgets is so that if you have a single line widget you can get up/down/page-up/page-down yourself, and if you have a non-submit widget you can get enter/return yourself.

In my app I have two places where I have a single-line text widget you can use to filter a list, and in one instance I'd like to scroll the list on page-up/down, and in another instance I'd like to be able to move the selected item in the list on up/down.

I'm on the fence about the submit vs. getting enter/return on your own. It's not like you have to use the submit event to do something with the text in the widget. They seem kind of equivalent, and I've been debating making my text widgets submittable again and just treating it like I do enter/return now. I'm not sure yet if that's the right way to go, for me, but it might be. So that one's arguable too.

I guess it's possible that someone might want to treat enter & return differently?

Indeed, but I like the short and readable set expressions. Would you also have the modifier names taken form package key?

No. To me they're not distinctive enough, that is, I rarely want to search for "ctrl keys". But I frequently want to search for enter/up/down/page-up/page-down keys.

This is also handy when viewing code in a browser. Try searching for ↑ in https://git.sr.ht/~eliasnaur/gio/tree/6ddc13ce6691291f298c6ebbcc08effa7ceb8a91/item/widget/editor.go. I mean, you can, but if you're like me then you had to copy the ↑ from somewhere. Whereas it's a lot easier to search for NameUpArrow.

https://github.com/gioui/gio seems to be behind https://git.sr.ht/~eliasnaur/gio/tree by 9 commits right now.

When it's up to date, I have a fix for this issue in https://github.com/theclapp/gio.

Right now, if I made a PR, it'd include those commits that I pulled from https://git.sr.ht/~eliasnaur/gio directly.

Feel free to cherry pick the relevant commits out of my fork directly.

Also if the Editor is Submit:false, then it shouldn't listen for return/enter.