[docs] iframe keyboard not working

[GregSlazinski]

I've tried on Chrome and Firefox and both have the same behavior.

if I open the demo directly: http://esenthel.com/site/Esenthel%20Fantasy%20Demo/Esenthel%20Fantasy%20Demo.html Then keyboard works OK. Click on "Menu / Options" and you can type something in the "Gui Scale" textfield in the menu window. or you can close it with "Escape" key.

But if I open the page through an iframe: http://www.esenthel.com/?id=live_demo Then keyboard doesn't work anymore, I press keys and nothing happens.

I use the following code: <iframe src="site/Esenthel Fantasy Demo/Esenthel Fantasy Demo.html" width="95%" height="520px" scrolling="no" webkitallowfullscreen mozallowfullscreen style="box-shadow:none;-webkit-box-shadow:none;border:none;overflow:hidden"></iframe>

[curiousdannii]

Works for me in Chrome 62/Windows 10.

[juj]

I can reproduce in Firefox Nightly 59.0a1 (2017-11-15) (64-bit) on macOS 10.12.6. Mouse does work and one can scroll the camera and click on the UI buttons, but typing numbers to the keyboard input field in the Gui Scale input field does not work.

What input API does Esenthel utilize? E.g. emscripten/html5.h, SDL 1.2 or SDL 2.0? How are the keyboard event handlers registered?

[GregSlazinski]

Hi,

I'm using html5.h

static EM_BOOL KeyPressed(int eventType, const EmscriptenKeyboardEvent *e, void *userData)
{
   Kb.putToBuffer(Char(e->charCode));
   return 1;
}
static EM_BOOL KeyDown(int eventType, const EmscriptenKeyboardEvent *e, void *userData)
{
   KB_KEY key=KB_KEY(e->keyCode);
   switch(e->location)
   {
      case DOM_KEY_LOCATION_LEFT: switch(key)
      {
         case KB_CTRL : key=KB_LCTRL ; break;
         case KB_SHIFT: key=KB_LSHIFT; break;
         case KB_ALT  : key=KB_LALT  ; break;
       //case KB_WIN  : key=KB_LWIN  ; break;
      }break;

      case DOM_KEY_LOCATION_RIGHT: switch(key)
      {
         case KB_CTRL : key=KB_RCTRL ; break;
         case KB_SHIFT: key=KB_RSHIFT; break;
         case KB_ALT  : key=KB_RALT  ; break;
       //case KB_WIN  : key=KB_RWIN  ; break;
      }break;
   }
   Kb.push(key);
   if(e->ctrlKey) // if control is pressed then we need to eat it to avoid browser taking over Ctrl+A, Ctrl+C, Ctrl+V, etc.
   {
      if(key>='A' && key<='Z')Kb.putToBuffer(Char(key + (e->shiftKey ? 0 : 'a'-'A')));else
      if(key>='0' && key<='9')Kb.putToBuffer(Char(key));
      return 1; // eat the key
   }
   return Kb.keyChar(key) ? 0 : 1; // if the key will generate a character then don't eat it (0) so KeyPress can get called, otherwise eat it (1)
}
static EM_BOOL KeyUp(int eventType, const EmscriptenKeyboardEvent *e, void *userData)
{
   KB_KEY key=KB_KEY(e->keyCode);
   switch(e->location)
   {
      case DOM_KEY_LOCATION_LEFT: switch(key)
      {
         case KB_CTRL : key=KB_LCTRL ; break;
         case KB_SHIFT: key=KB_LSHIFT; break;
         case KB_ALT  : key=KB_LALT  ; break;
       //case KB_WIN  : key=KB_LWIN  ; break;
      }break;

      case DOM_KEY_LOCATION_RIGHT: switch(key)
      {
         case KB_CTRL : key=KB_RCTRL ; break;
         case KB_SHIFT: key=KB_RSHIFT; break;
         case KB_ALT  : key=KB_RALT  ; break;
       //case KB_WIN  : key=KB_RWIN  ; break;
      }break;

      default: switch(key) // if there's no distinction between left/right on release, then release both TODO: test if this still happens
      {
         case KB_CTRL : key=KB_LCTRL ; Kb.release(KB_RCTRL ); break;
         case KB_SHIFT: key=KB_LSHIFT; Kb.release(KB_RSHIFT); break;
         case KB_ALT  : key=KB_LALT  ; Kb.release(KB_RALT  ); break;
       //case KB_WIN  : key=KB_LWIN  ; Kb.release(KB_RWIN  ); break;
      }break;
   }
   Kb.release(key);
   return 1;
}
static void SetCallbacks()
{
   emscripten_set_keypress_callback         (0, 0, 1, KeyPressed);
   emscripten_set_keydown_callback          (0, 0, 1, KeyDown);
   emscripten_set_keyup_callback            (0, 0, 1, KeyUp);
}

[simonzeiger]

I'm having the same issue, with SDL2. Any fixes?

[juj]

Thinking about the situation here, the issue may be that if one does mouse clicks inside an iframe and the input focus is on the parent, and if one returns 1 from the HTML5 mouse handler to cause event.preventDefault(); to be called on the mouse events, then the browser suppresses its default behavior, which includes passing input focus into the iframe. You can try dropping the return 1;s and/or event.preventDefault();s, or manually calling document.getElementById('iframe)'.focus(); to diagnose if that would fit the scenario here.

[indianakernick]

I put this in my pre-js file

setInterval(() => window.focus(), 500);

[stale[bot]]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

[ghost]

I have been unable to find a no-fuss solution to this, and I'm wondering if this really is a wontfix.

EDIT: The last solution works in Chromium, and the issue I'm experiencing is browser-specific, and only with a really ghetto browser so whatever.

[kripken]

Ok, let's reopen this then.

[ghost]

Ehh. If you want. Refocusing the iframe is in the scope of the website and not Emscripten IMHO. At most it needs a mention in the documentation, but I wouldn't do more than that.

On 2020-06-29 10:26 AM, Alon Zakai wrote:

Ok, let's reopen this then.

-- You are receiving this because you commented. Reply to this email directly, view it on GitHub [1], or unsubscribe [2].

Links:

[1] https://github.com/emscripten-core/emscripten/issues/5796#issuecomment-651257009 [2] https://github.com/notifications/unsubscribe-auth/ABSUA3XGURWB4ZFSSKCUAI3RZDFGDANCNFSM4ED666SQ

[kripken]

Sounds good, let's leave this open for a doc update that hopefully someone will want to do.

[stale[bot]]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[GregSlazinski]

Reopen