We just need to make sure all the throbber animations share a start
time, and we can use an arbitrary time (i.e., zero) rather than going
through all the tabs.
Differential Revision: https://phabricator.services.mozilla.com/D235300
Currently, when the tab strip is in focus, pressing the arrow keys currently switches the active tab only. With this change, pressing the arrow keys will continue to switch the active tab when the adjacent item in the tab strip is a tab, but tab group labels will also receive keyboard focus if they happen to the adjacent items in the tab strip. Now, pressing left/right allows the user to "select" each tab or tab group label in the tab strip.
Differential Revision: https://phabricator.services.mozilla.com/D233016
In certain cases when closing a tab(s), we temporarily lock the width of the tabs instead of letting them grow/shrink. If you close a tab and then quickly collapse a tab group right afterwards, you can end up with the tab group label going into the collapsed state correctly but the tabs in the tab group are still visible.
The issue is that we lock tab sizes on visible tabs using `max-width: ... !important` and we are hiding tabs in collapsed tab groups by using a CSS rule of `max-width: 0`. When we unlock the tab sizes, we only unlock visible tabs, but the tabs inside of the collapsed tab group are no longer considered visible.
This fix removes the tab lock size `max-width: ... !important` rule on all tabs regardless of tab visibility.
Differential Revision: https://phabricator.services.mozilla.com/D233022
- when creating a group from the front edge of a target tab, the target tab should be the last tab in the group
- when creating a group from the back end of a target tab, the target tab should be the first tab in the group
- the tab group should be created at the position of the target tab
Differential Revision: https://phabricator.services.mozilla.com/D230283
This is probably also a better reflection of reality now that we can
have vertical tabs which would by definition not be in the titlebar.
Differential Revision: https://phabricator.services.mozilla.com/D229767
This is probably also a better reflection of reality now that we can
have vertical tabs which would by definition not be in the titlebar.
Differential Revision: https://phabricator.services.mozilla.com/D229767
When all tabs are inside of tab groups, this patch allows the user to drag a tab to become a standalone tab at the end of the tab stirp. The user also has the ability to drop the tab into the end of the tab group at the end of the tab strip if the tab is dropped closer to the tab group.
Differential Revision: https://phabricator.services.mozilla.com/D229440
When closing the last visible tab, if there are any collapsed tab groups, make one of the tabs in a tab group active. Based on pre-existing behavior, activating a tab in a collapsed tab group causes the tab group to expand.
Currently, if you close the last visible tab while you still have collapsed tab groups present on the tab bar, the browser window will close. This is surprising and sad behavior for users.
Differential Revision: https://phabricator.services.mozilla.com/D228274
- you can now drag and drop when there are only 2 or 3 pinned tabs
- the position of the dragged tab has been fixed when scrolling overflow
Differential Revision: https://phabricator.services.mozilla.com/D227992
Currently, we provide a visual indicator + functionality to create a new tab group by dropping any tab onto any other tab. We think users will generally only use this to create new tab groups between standalone tabs; users are probably more likely to be making a mistake if they end up creating a new tab group by dropping a tab onto another tab that's already in a tab group. In order to prevent that, this patch just turns off the ability to create a new tab group by dropping onto any grouped tab.
Differential Revision: https://phabricator.services.mozilla.com/D228381
When all 9 tab group colors are in use, drag-drop code picks a random tab group color to highlight the tab drop target if the drop will create a tab group. The random pick is executed once per dragover event, so the color appears to change a few times a second. Kinda cool but distracting.
This patch chooses the next new tab group color on dragstart, saves that color on the drag data, and uses that color for all of the presentation + logic for creating a new tab group from a drop. The color will still be random when there are many tab groups, but the color will stay the same throughout a single drag operation.
Differential Revision: https://phabricator.services.mozilla.com/D228386
