Let Gecko choose a suitable size. This seems to result in the desired
behavior (same as Ctrl+N). Tested GNOME and Kwin, X11 and Wayland.
The reason for the behavior change here is because `outerWidth` before
the regressing patch returned the inner, not the outer width. Combined
with the pre-existing behavior that decorations are added asynchronously
by the window manager, it just happened to conveniently cancel out that
bug, which is now fixed.
It's unclear we need this at all on macOS fwiw. IIRC Cmd+N does also the
same thing as Windows, so maybe we can remove this block altogether.
Separate patch tho, as I don't have a macOS build ready to test it this
very moment, but I think it should just work.
Differential Revision: https://phabricator.services.mozilla.com/D236867
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
