tabindex issue

[vipdorian]

If there more than one element with tabindex >= 0, when the sidebar is opened a second time, tabindex is set to "-1" to all alements except first one.
To reproduce the bug,

1. Browse to https://echeung.me/ng-sidebar/
2. Click on "Opened"
3. In Chrome inspector, change a <closesidebar=""> FOR <closesidebar="" tabindex="1">
4. Click on "This will close the sidebar too"
   5 If click again on "Opened", the tabindex will be at "-1" instead of 1.

[arkon]

I actually tried setting the button to have a tabindex of 2 and the anchor with closesidebar to 1. They both seem fine after opening/closing multiple times. Did you do anything else too?

[vipdorian]

Hi,
see here https://www.youtube.com/watch?v=AQdweW2cXGI&feature=youtu.be

[arkon]

@vipdorian I don't think the video's permissions are set to public.

[vipdorian]

Ok, try this one https://youtu.be/AQdweW2cXGI 2017-04-24 22:53 GMT-04:00 Eugene Cheung <[email protected]>:

…

@vipdorian <https://github.com/vipdorian> I don't think the video's permissions are set to public. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#72 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJrNjCybd4Wak38KQssbzXA0zEfkWUNHks5rzWBGgaJpZM4NG5ag> .

[arkon]

@vipdorian Thanks, the video works now. I can reproduce it on my end too, so I'll be looking into this in the coming days.

[arkon]

This is actually pretty hard to reproduce consistently, but I did look over the code and made some small edits that should hopefully fix this. Feel free to reopen this if it's still happening in v4.2.2+.

[vipdorian]

Hi,
Thanks for the quick response.
I upgraded to 4.2.2 and I can reproduce it.
You can find a live example at http://ci.prescription.dorianpharmatech.com/pharmacie

I think the problem is in sidebar.component.ts at around line 411.
If the element does not have a property tabindex, it's tabindex should be set to 0.
Try to change
if (existingTabIndex !== null) {
el.setAttribute('tabindex', existingTabIndex);
}
by
if (existingTabIndex !== null) {
el.setAttribute('tabindex', existingTabIndex);
}
else {
el.setAttribute('tabindex', '0');
}

[arkon]

I don't think explicitely setting a tabindex is correct either. After all, elements don't have it normally anyway.

[vipdorian]

Yeah you're right. But, setting tabindex="-1" for elements which had no tabindex property is worst. It means that elements which were tabable are not tabable anymore. I think the solution would be : if the element did NOT have a tabindex property, to not setting one when the sidenav is opened again. 2017-04-26 20:05 GMT-04:00 Eugene Cheung <[email protected]>:

…

I don't think explicitely setting a tabindex is correct either. After all, elements don't have it normally anyway. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#72 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJrNjFhvMGrNOZrUXqE80Vd2HyvNagU4ks5rz9vHgaJpZM4NG5ag> .

[arkon]

That's intentionally done so that the elements aren't focusable when the sidebar is closed (and presumably out of the visible viewport). The current logic should already account for removing the tabindex if there was none initially.

[k-schneider]

I have a collapsible menu inside of an ng-sidebar. When the parent items are closed I set tabindex to -1 for children:

[attr.tabindex]="item.open ? 0 : -1"

The sidebar appears to completely blow away any custom tabindex I'm setting though. Is there any way to disable this behavior?

Edit: It appears to be an issue with having the sidebar opened initially when the page loads. After looking at how this lib tracks tabindex I tried adding a small delay to when the sidebar opened flag is flipped to true (based on screen size) and this seems to have fixed the issue with the initial custom tabindex being lost.

[arkon]

Yeah, it's because it removes any tabindex value assuming that it was previously set as -1 when closing the sidebar. I can probably throw together a workaround tonight.

[arkon]

@k-schneider That issue should be fixed in v7.1.0.

[k-schneider]

Thanks! But something funky is still happening if the user closes/opens the menu too quickly. The indexes are not being restored as expected.