Trapping keyboard tab doesn't work on aggregation of tabset and modal

[e-cloud]

Traping tab feature on the modal module is really nice. But i have some trouble with the new feature.

i use a tabset in the modal. when i update to v0.13.2, my modals without tabs work as expected, but it turn to tabs and modal aggregation, it can only trap the tab key on the second tab of the tabset.

here is a plukr that reproduce the problem.
http://plnkr.co/edit/wwgZhXu0fru4L703z5by?p=preview

i'm not sure if i use it on the wrong place or the modal source code has some bugs not concerned yet.
can somebody offer some help?
@wesleycho, @paulorbpacheco

[wesleycho]

I am a bit confused - do you want the tabbing to be trapped in the tabs, or are you not able to access the last tab? If it is the latter, tabbing is allowing me to access the first tab as well.

It looks like what happens is that the tabbing does not get trapped in the first tab (when the modal is first opened) - this needs some investigation.

[e-cloud]

@wesleycho, yes, my problem is just the tabbing does not get trapped in the first tab

[moacir-selinger]

Hello!

I have the same problem, but without the tabs. I have a modal with some fields and when I sail through Tab after the last element of focusable modal, the focus begins to navigate the elements below the modal. What should I do will make it stop happening, and have updated the resource for the 0.13.3 version, which from what I understand, has the solution to the problem.

Thank you for your help!

[wesleycho]

@hassed can you post a reproduction of your situation? More information would help to see whether it is something that is related to this specific issue or a separate one.

[moacir-selinger]

Hello @wesleycho, thanks for the help. It was very difficult to get simulate the problem, and is the complex structure of resources here and there are many dependencies injected. It follows the problem occurring, but from what saw at this time when preparing the simulation as well as tests that did without our structure, it seems to me that the problem has now passed for us. Thank you for your attention and feel free if you want to still take a look.

[moacir-selinger]

Sorry @wesleycho, I managed to apply the opening of modal more directly and the problem did not occur. The fault is all ours, thanks for the help!

[leofachini]

Seems to be that the focusableElementList array has some invisble elements on it and it considers his last element the cancel button of the change tab. If you click in the change tab and keep hitting tab key you will realize that it will be trapped here and work as expected. Anyway, we will have to adjust the code to consider the possibility of the last tab key isn't visible.

[leofachini]

I had to change the code to consider the tabs inside the modal. When a tab is present in a modal, we must consider only the focusable elements contained by the active tab(the visible tab) and discard the others that are in the inactive tab. Nonetheless, when this specific scenario occurs, on every tab event we must refresh the list of focusable elements.

Here is the snippet of code that has been changed:

$modalStack.loadFocusElementList = function(modalWindow) {
  if (modalWindow) {
    var modalDomE1 = modalWindow.value.modalDomEl;
    if (modalDomE1 && modalDomE1.length) {
      var tabPanels = modalDomE1[0].querySelectorAll('.tab-pane:not(.active)');
      if (tabPanels.length !== 0) {
        focusableElementList = Array.prototype.slice.call(modalDomE1[0].querySelectorAll(tababbleSelector));
        var ignorableElementList = [];
        for (i=0; i < tabPanels.length; i++) {
          ignorableElementList = ignorableElementList.concat(Array.prototype.slice.call(tabPanels[i].querySelectorAll(tababbleSelector)));
        }
        for (l=0; l < focusableElementList.length; l++) {
          for(j=0; j < ignorableElementList.length; j++) {
            if (ignorableElementList[j].ng339 === focusableElementList[l].ng339) {
              //Remove the element from the arraylist
              focusableElementList.splice(l,1);
            } 
          }
        }
      } 
      else if (focusableElementList === undefined || focusableElementList.length === 0) {
        focusableElementList = Array.prototype.slice.call(modalDomE1[0].querySelectorAll(tababbleSelector));
      }
    }
  }
};

Here is the working plunker.

By the way, I have seen this snippet below around the code, anyone can tell me if this is a valid snippet of code, because it always returned true regardless the array length.

if (!myImaginaryArray.length0) { //I want to know about this line of code.
  //Things goes on
}

[icfantv]

Closing in favor of #4772.

[widmoser]

Are there any compelling reasons for not creating a PR out of the code snippet of @leofachini. I have the same problem and need a fix soon. If it is not integrated into the code base I will have to resort on working with a fork...

[icfantv]

@widmoser, looking at this more closely, I'm not sure this is an ARIA Accessibility issue. @wesleycho, do you recall what your thoughts were when tagging this?