Firefox View: The view's tab bar position index depends on the order which the view's tab has been selected
Categories
(WebExtensions :: Frontend, defect)
Tracking
(Not tracked)
People
(Reporter: mckravchyk, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0
Steps to reproduce:
- Set the browser to restore previous tabs on startup
- Click some tabs and finally click on the Firefox View tab
Actual results:
browser.tabs.query({}) shows the Firefox View position to be non-0. This position seems to depend on how many tabs were clicked on previously. I.e. all tabs are in a discarded or semi-discarded state, if I click on 3 tabs and the view is the 4th tab I clicked on, the tab.index property will be 4 (or something around that).
Expected results:
tab.index should always be 0.
Also, should this even pop up in the tabs API in the first place? It's not a regular tab by any means. I also noticed that there's no way to filter it out properly when processing regular tabs, a bug which I yet have to submit.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
|
Reporter | |
Comment 3•3 years ago
|
||
I mean, Firefox View index should be 0, because it's the first "tab" in the tab list. If the tab list is like:
- FW
- Tab 1
- Tab 2
- Tab 3
- Tab 4
I expect the indexes for these tabs to be 0, 1, 2, 3, 4 respectively.
but it is 3, 0, 1, 2, 4
|
|
Reporter | |
Comment 4•3 years ago
|
||
- and it depends on the order of selecting the tabs. FW has an index of 3 because it's the third tab that I selected. Other tabs behave normally.
|
|
Reporter | |
Comment 5•3 years ago
|
||
By "FW" I meant "FV".
|
||
Comment 6•3 years ago
|
||
There are reasons why it's not at index 0 anymore, having to do with how existing logic with regards to pinned tabs and tab navigation is implemented - see bug 1787979 (it may not be obvious in that bug, but the position at the tab was changed to not be deliberately placed at index 0).
|
|
Reporter | |
Comment 7•3 years ago
|
||
(In reply to Sarah Clements [:sclements] from comment #6)
There are reasons why it's not at index 0 anymore, having to do with how existing logic with regards to pinned tabs and tab navigation is implemented - see bug 1787979 (it may not be obvious in that bug, but the position at the tab was changed to not be deliberately placed at index 0).
but will this issue be considered? I don't know the details about introducing that other change, but maybe there's another way to fix it? This change means that the Tab.index no longer represents a valid position. Notice the jump: 3, 0, 1, 2, 4 - those first tabs have invalid positions and there's a gap in the tab bar's order, one of the tab's will have a +2 index compared to the tab immediately to the left.
|
|
||
Comment 8•3 years ago
|
||
(In reply to Maciej Krawczyk from comment #7)
(In reply to Sarah Clements [:sclements] from comment #6)
There are reasons why it's not at index 0 anymore, having to do with how existing logic with regards to pinned tabs and tab navigation is implemented - see bug 1787979 (it may not be obvious in that bug, but the position at the tab was changed to not be deliberately placed at index 0).
but will this issue be considered? I don't know the details about introducing that other change, but maybe there's another way to fix it? This change means that the
Tab.indexno longer represents a valid position. Notice the jump: 3, 0, 1, 2, 4 - those first tabs have invalid positions and there's a gap in the tab bar's order, one of the tab's will have a +2 index compared to the tab immediately to the left.
Maybe Dão can comment on this.
I would point out that there's no guarantee the fxview button is to the left of the tabstrip (the user could move it wherever) so I honestly don't know why it would be super important (or necessarily correct) for the index to be 0, from the webextension perspective.
|
|
Reporter | |
Comment 9•3 years ago
|
||
(In reply to :Gijs (he/him) from comment #8)
(In reply to Maciej Krawczyk from comment #7)
(In reply to Sarah Clements [:sclements] from comment #6)
There are reasons why it's not at index 0 anymore, having to do with how existing logic with regards to pinned tabs and tab navigation is implemented - see bug 1787979 (it may not be obvious in that bug, but the position at the tab was changed to not be deliberately placed at index 0).
but will this issue be considered? I don't know the details about introducing that other change, but maybe there's another way to fix it? This change means that the
Tab.indexno longer represents a valid position. Notice the jump: 3, 0, 1, 2, 4 - those first tabs have invalid positions and there's a gap in the tab bar's order, one of the tab's will have a +2 index compared to the tab immediately to the left.Maybe Dão can comment on this.
I would point out that there's no guarantee the fxview button is to the left of the tabstrip (the user could move it wherever) so I honestly don't know why it would be super important (or necessarily correct) for the index to be 0, from the webextension perspective.
I'm not familiar with that feature, I have seen it the first time when I tried the developer edition (107) and I could not find an option anywhere to move it, so I thought it's fixed at position 0. If it's in fact moveable, then I'd expect it to be treated as any other tab regarding its index position.
|
||
Comment 10•3 years ago
•
|
||
(In reply to Maciej Krawczyk from comment #7)
(In reply to Sarah Clements [:sclements] from comment #6)
There are reasons why it's not at index 0 anymore, having to do with how existing logic with regards to pinned tabs and tab navigation is implemented - see bug 1787979 (it may not be obvious in that bug, but the position at the tab was changed to not be deliberately placed at index 0).
but will this issue be considered? I don't know the details about introducing that other change, but maybe there's another way to fix it? This change means that the
Tab.indexno longer represents a valid position.
It depends on how you define valid. If you expect the index to represent the visual position within visible tabs, then yes, this would be invalid, but it would also be invalid for any other hidden tab. Based on https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/Tab, I don't believe the API promises what you expect, and I don't see much of a practical way to make it work like you suggest. What should index report without breaking existing API consumers? -1 seems like it would likely break existing code. It sounds like you'd prefer 0, but how would that work for multiple hidden tabs? Anyway, I'll move this bug over to the WebExtension component.
(In reply to Maciej Krawczyk from comment #0)
Also, should this even pop up in the tabs API in the first place? It's not a regular tab by any means. I also noticed that there's no way to filter it out properly when processing regular tabs, a bug which I yet have to submit.
Have you considered filtering out hidden tabs?
(In reply to Maciej Krawczyk from comment #9)
I'm not familiar with that feature, I have seen it the first time when I tried the developer edition (107) and I could not find an option anywhere to move it, so I thought it's fixed at position 0. If it's in fact moveable, then I'd expect it to be treated as any other tab regarding its index position.
You can move hidden tabs but since the tab element is hidden you won't see that in the tab strip. In that sense, the tab was movable even when we inserted it at position 0. Bug 1787979 hasn't changed that.
|
|
Reporter | |
Comment 11•3 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #10)
Have you considered filtering out hidden tabs?
I have overlooked that it is a hidden tab.
You can move hidden tabs but since the tab element is hidden you won't see that in the tab strip. In that sense, the tab was movable even when we inserted it at position 0. Bug 1787979 hasn't changed that.
Alright. I think I get it now. Firefox View is a hidden tab. I have to consider that tabs can be hidden and retain their index position, which means that the index of a non-hidden tab will not necessarily equal "tabToTheLeftIndex + 1"
Description
•