Incorrect focusing in FireFox

[streamcode9]

Code example: http://jsfiddle.net/streamcode9/fp5pE/

In example, I have two rows. In the first row tabulations work fine, but in the second one I have to press TAB two times to focus next CHOSEN element. I have noticed, that the bug is reproduced in FireFox and only when CHOSEN drop-down-list has a scroll(without it works fine).

[pfiller]

This is an old issue and I am not seeing this in the current version of Chosen with the current version of Firefox. If the problem still exists, please re-open and update the Fiddle to use current assets.

[SimonBrodtmann]

The bug ist still there. I updated the fiddle to reproduce the bug. New fiddle: http://jsfiddle.net/93f7A/1/

[tjschuck]

@SimonBrodtmann What OS and version are you on, and what version of Firefox exhibits the issue? We'll reopen once you provide that info.

[SimonBrodtmann]

Windows 7 x64 and Firefox 23.0.1 (portable)

[tjschuck]

@harvesthq/chosen-developers Leaving it to you guys with all your fancy VMs to reproduce.

[lode]

I think the updated fiddle from @SimonBrodtmann actually describes another issue as it uses multiple selects, see https://github.com/harvesthq/chosen/issues/169 & https://github.com/harvesthq/chosen/issues/244 (even though they also mention single selects, once you read them carefully, it describes a multi select problem).

I've updated the fiddle with what I think is the original issue: http://jsfiddle.net/fp5pE/13/

1. Click the first input
2. Tab through to the next select
3. It gets focus and opens
4. Use the cursor to pick an option
5. Tab
6. The option is selected and focus remains on the select

I expect the focus to move to the next input field, as happens on the third row of normal (non-chosen) selects. Pressing tab while inside a single select should select the option and move to the next input.

The problem gets worse w/o tabindex. Then after using a second tab (to move to the next input), focus is gone first, a third tab is needed to go to the next input.

I'm experiencing this on Ubuntu 14.04 with Firefox 39. With Chrome (v44) it is a whole other story; the normal non-chosen select acts the same, and thus chosen does the same as native. And the w/ or w/o tabindex is no difference.

[lode]

I've been able to "hack" into the tab behavior to do continue to the next input.

$(document).on('keydown', '.chosen-search input', function(event){
    var keyCode = event.keyCode || event.which;
    if (keyCode == 9) {
        var tabindex = parseInt($(this).attr('tabindex'));
        var tabindex = (event.shiftKey) ? tabindex-1 : tabindex+1;
        if ($('[tabindex="'+ tabindex +'"]').length > 0) {
            $('[tabindex="'+ tabindex +'"]').focus();
            event.preventDefault();
        }
    }
});

(I'm not able to put this in a fiddle due to a CSRF check.)

Right now this only works for my specific use case where I have a tabindex on all inputs/selects (thus also the .chosen-search input) except for the input[data-rel="chosen"].

In my project I even replaced the .focus() with a $('[tabindex="'+ tabindex +'"]').parents('.chosen-container').prev('select').trigger('chosen:open') if the next element is a chosen box as well to open it directly.

[kbhagchandani]

I am done with following solution just need to incorporate into the plug in

$('html,body').animate({
    scrollTop: $('select').data('chosen').container.offset().top
});

[koenpunt]

Is this the issue being described? I have an eventlistener on focus, which logs the event target.