Encountered this while working on bug 612577. The code there adds a check using this: tab.mode.tabs.indexOf(tab) In the closeTab() function. However it would appear that on all platforms this will always return 0. To test this I set a log statement in the function and then closed some tabs. The values are correct until we reach the add-on tab. I will add a video proving these findings shortly.
Actually appears worse than I thought. Opening either a chat or add-on tab causes this behavior: Inbox(Main) Tab | Opened Mail 1 | Opened Mail 2 | Chat/Add-on Tab | Opened Mail 2 | | | | | | Doesn't matter 0 1 0 1 When we should get: Inbox(Main) Tab | Opened Mail 1 | Opened Mail 2 | Chat/Add-on Tab | Opened Mail 2 | | | | | | Doesn't matter 0 1 2 3 The Chat/Add-on tab seems to reset the index logic. I am unaware of why this is the case.
Summary: tab.mode.tabs.indexOf the add-on tab always returns 0 → Chat and add-on tabs always will return 0 when using indexOf and cause following tabs to return incorrect values.
Created attachment 787672 [details] [diff] [review] Example/issue patch. Patch allows demonstration of the issue in the Error Console.
More Notes: Testing shows the correct amount of child nodes in the tab bar. Getting the selected index also shows the correct value. So this issue is indexOf specific.
Working as expected - as discussed in IRC: (mconley) so, each tab has a "mode" - this mode is registered with tabmail. Each tab also has a reference to the parent mode that it belongs to (mconley) so, tab.mode.tabs is the equivalent of saying "for this tab, return to me all of the tabs of the same type (inclusive)"
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.