Switching Windows With Alt+Tab Sometimes Triggeres Next Step

[m42e]

Switching between windows using Alt+Tab triggers next event when switching to browser most of the time.

I'm not sure how to get rid of this but at least it is mentioned here ;)

[bartaz]

It was already reported somewhere... Probably long time ago...

It should be checked if modifier keys (alt, ctrl, meta) are pressed with tabs (and arrows) and not trigger the next action.

[aliva]

can't you just remove tab navigation complelty?

I mean this:

event.keyCode === 9

[regebro]

Checking modifier keys doesn't help. I tried to fix this today, but the fact is that when you switch to w browser window with Alt-Tab, the event sent is a normal Tab event. This is on Ubuntu both with Firefox and Chrome. I don't know where the bug is, but the only solution I can find for the time being is to not support the Tab button for the event...

[bartaz]

But, if you don't have an event on Tab key it will have its default behavior in browser - going through focusable elements (like links, form elements, etc). And this may sometimes break what impress.js shows, as browser will catch focus on some element, try to scroll to this element, so presentation will visually move until next slide is shown.

Weird, doesn't happen all the time, but that's the main reason why I added Tab key support for moving slides.

[diogovincenzi]

I recently tried this library for a presentation and ran into the same issue using Windows. Every time I alt + tabbed to chrome where the presentation was running, it would go to the next slide. It's a little bit distracting when developing the slides I think. Maybe add a quick option to disable it if needed? This way we can disable it while building the slides, and then switch it on again for normal presentation behaviour.

[regebro]

In that case I think that the TAB key should be caught, and set so that the default is ignored, but that it doesn't advance to a slide. Just removing the "case 9:" row would do that, I think.

[bartaz]

@regebro Yes, you are probably right. That may be the easiest solution.

[leroy0211]

You can add a configuration which keys are attached to next and back. Also the option to autoscroll every X-seconds would be very easy. Or an option to set data-timeout to the dom element, and scroll it after that specifoc time has past.

You might get something like (just as an example):
$('#impress').impress({
nextkeys: [9, 12],
previouskeys: [13],
scrollinterval: false (or 10),
helptimeout: 20
});

This would be user defined which method(s) you want to use

[Ivanca]

+1 @leroybaeyens
Having full control of the key bindings would be really useful.
BTW thanks for your awesome work in this library @bartaz.

[eddiemonge]

can people try this solution and let me know what you find? #312

[olegccc]

Very annoying 'feature'. I don't know why clicking 'tab' should work for slide change, it is not obvious.
If I, for example, want to show some additional info during the presentation, each time I return to the slides it moves to next slide.

Anyway this workaround can help:

    document.addEventListener("keyup", function(event) {
        if (event.keyCode === 9) {
            event.stopImmediatePropagation();
        }
    });

(include it before impress.js)

[ltregan]

So, here is what is happening.... (at least Windows)

If you are on application A, you press Alt+TAB to switch to the Impress browser. If you are like me, you will release Alt before TAB - at which point the focus goes to the browser with TAB pressed and Alt up.

You then release TAB: the browser receives a keyUp event, and a move to the next slide is triggered. Since Alt is not pressed at that time (remember - it was released before the browser got the focus) checking for event.getModifierState( KeyboardEvent.altKey ) does not help.

The correct solution is thus I believe not to move to next slide upon pressing TAB.

[m42e]

maybe a better solution is to memorize if the tab key has also triggered a keydown event. If not, ignore the keyup, else move forward to the next slide.

[m42e]

Thanks for the analysis @ltregan .

[ltregan]

"maybe a better solution is to memorize if the tab key has also triggered a keydown event. If not, ignore the keyup, else move forward to the next slide." => oh yes, that would work too if we want to keep the TAB key active !

[FagnerMartinsBrack]

@m42e @aliva @regebro @diogovincenzi @leroy0211 @Ivanca @eddiemonge @olegccc @ltregan

Can anybody check if this is still an issue on master?
Also, check this comment. This seems to be a bug with Chrome, can anybody confirm if that is fixed or if there is any open issue for Chrome team?

[aliva]

@FagnerMartinsBrack dude, It's been 4 years from my comment, I can't even remember what is impress.js 😆

[FagnerMartinsBrack]

@aliva Yeah I understand. See this comment though, we are trying to get this project on it's track again and looking for anyone that is still willing to help.

[FagnerMartinsBrack]

Related to #550 (comment)

[FagnerMartinsBrack]

According to #550 (comment) it seems this was already fixed. I couldn't reproduce it in the master branch.

We will close this for now and watch to see if this will come up again.