Fix focus and hovering on context menu show/hide

[planger]

• Restore focus of diagram after context menu is closed
• Cancel hover timer when diagram looses focus
• Clear hover state when diagram looses focus

Note that there is a separate hover issue with edges and handles, which is fixed in Sprotty directly. See eclipse-sprotty/sprotty#264

Fixes eclipse-glsp/glsp#496
Fixes eclipse-glsp/glsp#497

Contributed on behalf of STMicroelectronics.

[martin-fleck-at]

Hello Philip, thank you very much for your contribution! For me, the hiding of the popup works as expected. However, the restoring of the editor focus/active state does not show the expected behavior for me:

All the methods you implemented are triggered but the tab/editor does not appear to be 'active', i.e., the font is not white as it is for text editors. You can also see this if you have a selection with purple resize handles but after opening and closing the context menu the resize handles are gray.

I assume we need some kind of handling in the Theia integration. We already do it in one direction, i.e., in the glsp-diagram-widget we listen to the focus state change of the shell and send a FocusStateChangeAction to our widget if we become inactive. However, for FocusStateChangeActions we never set our widget as active in the shell. But that is just a guess from looking at the code, maybe something else might be necessary as well.

What do you think?

[planger]

@martin-fleck-at Thanks for the review!
Strange it worked reliably when testing yesterday, but today I indeed could reproduce your behavior from time to time. Debugging further it looks like focusing some SVG elements, like a label, isn't effective -- at least not to a degree that Theia detects that a child is focused and the tab should be activated again.
I now changed the code so that we always navigate up to the containing parent SVG element and invoke focus() on that. With that, I couldn't reproduce the unintended behavior you recorded above.

Can you please double-check if you can't reproduce it either with those changes?

Thanks!

[planger]

However, for FocusStateChangeActions we never set our widget as active in the shell. But that is just a guess from looking at the code, maybe something else might be necessary as well.

Theia should automatically activate a widget, if one of its child DOM elements receive focus. So it shouldn't be necessary to actively invoke some additional behavior in Theia.
The only thing that's necessary is to let GLSP know that the diagram became active or inactive when the user switches tabs, because this won't trigger any event in the GLSP diagram DOM part. Therefore we have this code:
https://github.com/eclipse-glsp/glsp-theia-integration/blob/526ad85a6a0004aad8bec77ef500891f0ebfc800/packages/theia-integration/src/browser/diagram/glsp-diagram-widget.ts#L168

[martin-fleck-at]

@planger Thank you for the explanation and the fix! With it everything works now as expected. However, you added an unnecessary injection which I think we should remove.

[martin-fleck-at]

Looking good now, LGTM!

[planger]

Thanks @martin-fleck-at for the thorough and fast review!