Keyboard shortcuts sometimes do not work until after a clicked command is executed

[Flamenco]

I click the file icon, then hit F2 or Space. The shortcut does not work.
Next, I manually click the preview icon and then close the preview.
Now all shortcuts work as expected.

Has anyone else seen this behavior? This is on a page with other JS libraries, so I am not sure who the culprit is.

[Flamenco]

Also, the shortcuts begin to work after if I context-click a file.

[nao-pon]

@Flamenco

When the focus shifts to other than the node of elFinder so elFinder become disabled. There is a UI option enableAlways to always enabled.

var options = {
    url  : 'php/connector.php',
    enableAlways : true 
}
$('#elfinder').elfinder(options);

In addition, elFinder next version will have the client configuration option enableByMouseOver to enable by mouse over.

Thanks!

[Flamenco]

But I click on a file in the finder and then issue the shortcut. Surely that should get the focus.

Also I tried setting
enableAlways : true
with no luck.

I would love to get this working, so any insight would be greatly appreciated.

Thanks!

[Flamenco]

Works for me on the demo, so something in my use-case must be stealing the focus. I am wrapping the component in Vaadin...

[Flamenco]

execShortcut is not getting called until after I manually execute a command. Must be a jquery issue, as execShortcut is definitely getting registered.

Also, opening the context menu is enough to get the callback working.

No keyboard events are sent from jquery until after I run a command by clicking a command button.

[nao-pon]

Also I tried setting
enableAlways : true
with no luck.

OK, I'll check it.

[Flamenco]

jquery.dispatch is not getting called with the keydown event, so something is disabling, or re-enabling the on('keydown'). The click event works fine.

[nao-pon]

@Flamenco I modified about an option enableAlways. Would you try and check enableAlways: true with nightly build?

[Flamenco]

Hi Nao-Pon,

I spend a few hours on this today.

First i thought it was because I had 2 jquery libraries, but dealing with that did not solve the problem. Then I thought it might be related to jquery v2.2. Next, I thought my issue was that there was another library calling $(document).keyup instead of $(document).on('keyup'). That did not solve the issue.

The other library's keyup handler was is getting called, while the elFinder handler was not.
Once I executed any elFinder command, the situation was reversed and elFinder received the event instead.

So this breaks it
$(document).on('keyup', function (e) {
console.info('key up called on external handler');
});`

and this fixes it.

$(document).on('keydown', function (e) {
console.info('key down called on external handler');
});`

Bottom Line: Registering a keyup listener causes the issue. Perhaps that needs to be handled when initially setting up handlers in elFinder?

Thank you so much for your attention on this. Please let me know if you can repeat this.

[Flamenco]

Actually, that did not fix the problem. Still can't figure this one out. :(

I am running it inside an iframe. Maybe that's the issue...

[Flamenco]

OK. Got it.

The issue happens when running in elFinder inside an iframe.

Putting this in index.html, it does not get called until a command is executed. Then it works from that point on.
$(document).on('keydown', function (e) { console.info(e); });

This works.

$(top.document).on('keydown', function (e) { console.info(e); });

This was my quick hack.

// attach events to document
    $(top.document)
        // disable elfinder on click outside elfinder
        .on('click.'+namespace, function(e) { enabled && !$(e.target).closest(node).length && self.disable(); })
        // exec shortcuts
        .on(keydown+' '+keypress, execShortcut);

So the not-breaking solution may be to add topDocument to the options, with a default value of document. And then bind events to that.

[nao-pon]

@Flamenco Thanks for your debugging.

$(top.document).on('keydown', function (e) { console.info(e); });

I think this is not good idea. It might trouble occurs when there is other content in the parent window.
Because the cause is that the window that contain the elFinder loses focus, I'm going to fix it.

[Flamenco]

Yes, when my iframe closes, the keyboard input on spaces and return is completely broken. Thats why I called it a 'hack'. I think It may also break the preview window nav controls.

[nao-pon]

@Flamenco I edited. Please try and check with enableAlways: true on nightly build.

[Flamenco]

+1 Nice Work Naoki!