lil-gui retaining focus on Windows?

[dboddy]

Hi,

My main js module has the following:

window.addEventListenter('keydown', onKeyDown, false);

I have noticed that after either:

• un/ticking a checkbox in my lil-gui
  *entering a value into text field

...this event no longer fires; I have to do some other interaction in my webpage (e.g. showing / hiding an item such as my custom tree-view) before it once again will detect a keydown event.

It seems as though lil-gui retains focus even after clicking back onto the webpage. For example, if I:

• Select a text input in lil-gui
• Enter any value
• Click back on the webpage (i.e. outside of the lil-gui window)

...then any key I press (which I would expect to be handled by onKeyDown()) actually appears in the lil-gui text input field

The issue is occurring on Windows 10 version 22H2 (we use at work), though my home version (on Mac High Sierra!) does not have this problem.

Regards

[georgealways]

Hi there,

So this is partially intended behavior. All controllers are supposed to stop the propagation of keypress events while they have focus:

lil-gui/src/Controller.js

Lines 82 to 84 in ad90324

	// Don't fire global key events while typing in a controller
	this.domElement.addEventListener( 'keydown', e => e.stopPropagation() );
	this.domElement.addEventListener( 'keyup', e => e.stopPropagation() );

The point is to prevent someone from, say, triggering global WASD controls while typing in a text field. But I'm surprised to hear that the events are still being captured after clicking elsewhere (and only on Windows?)

For the time being you could comment out those lines, but I recall there being some conversation around making this behavior optional. (#69)

Thanks for flagging this.

[dboddy]

Hi,

Many thanks for your reply. Your suggestion of commenting out those 2 line has resolved the issue for me, so that's great - thanks.

[dboddy]

...I understand the need for this behaviour in other circumstances so the idea of it being optional is a good one.

If I get any other insights as to why it seems to be a problem (for me) on Windows only, I will post it here. My old Mac is running an old version of Safari, so maybe it's "special" in some way (maybe just too old to interpret those 2 lines as expected)

Thanks again for your help.
BTW, this tool is a great replacement for dat-gui, which had several o/s issues for me, and adopting it was as easy as promised, with just a couple of small updates as documented in the Migration section.

Cheers,
Dave

[AlaricBaraou]

edit: what is described below has been proven wrong, see #136 (comment)

Just a comment to share that I'm experiencing the same issue.
A click on a button will retain focus ( this is normal native behavior ) and same with an input etc.
But once these have the focus, if your page have nothing else to focus on click ( mine just have a canvas ), the focus will remain on those elements and we lose all event listeners that rely on keydown, keyup.

Removing focus when clicking on anything else than the currently focused element fix that.

  // make lil-gui clear focus and resume keydown keyup events
  document.addEventListener('click', function(event) {
      // Get the currently focused element
      const focusedElement = document.activeElement;

      // Check if the click target is not the focused element and if there is a focused element
      if (focusedElement && focusedElement !== event.target && !focusedElement.contains(event.target)) {
          // Blur the focused element
          focusedElement.blur();
      }
  });

But ideally these two lines shouldn't be used outside of gui elements that requires keyboard interaction.

// linit to text input maybe ? Or make this an option ? 
this.domElement.addEventListener( 'keydown', e => e.stopPropagation() ); 
this.domElement.addEventListener( 'keyup', e => e.stopPropagation() ); 

Hopes this helps, thank you for this lib!

[georgealways]

Thanks for your comment @AlaricBaraou. I think a future version of lil-gui will likely include some flag like new GUI({ stopPropagation: false }). It would allow the user to manage event propagation manually.

I'm not able to reproduce the following however:

But once these have the focus, if your page have nothing else to focus on click ( mine just have a canvas ), the focus will remain on those elements and we lose all event listeners that rely on keydown, keyup.

Clicking elsewhere when a form element is focused should cause that element to blur automatically. Testing here: https://lil-gui.georgealways.com/examples/basic

But yes, I think the issue has come up enough that there should be a flag.

[AlaricBaraou]

@georgealways Apologies, it looks like you're right. I found the cause in my test environment, one of my other lib had a preventDefault() on the event where I was clicking, which would prevent the blur from happening.

I withdraw what I said. Sorry for the misinformation.