Handle tabs like other gnome apps

User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

Originally sent to Launchpad: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/241937

I have noticed that dragging tabs in Firefox does not work like in other gnome apps.

Basically, you can drag tabs along the tab bar to change their order, like in so many gnome apps. But you can also drag them up and down: if you accidentally drag them up and drop them on the bookmark bar, you add a bookmark for it. and if you accidentally drag it down to the browser area, you load that page again.

As you can see in the attached screenshot, the "good" area is quite small compared to the "bad" areas, so it's actually very easy to miss and drop the tab on a wrong place, and perform an action you didn't want. I propose that tabs in Firefox should behave just like gnome apps, and be able to move only left or right.

If you don't agree because you like being able to easily adding a bookmark or loading a page, think that the same exact effect can be achieved by dragging the favicon instead of the tab.

Reproducible: Always

Steps to Reproduce:
1.Drag a tab left or right
2.Accidentally miss and unadvertedly move it up or down
Actual Results:
The browser opens the URL / a new bookmark is created

Expected Results:
The tab changes places with other tabs, either left or right.

Created attachment 334128
Screenshot

First off, this is an enhancement request.
Second, why should we not enable people to move the tab up or down? That is standard FF functionality, and should not be removed.

Moving the Favicon is not very accessible in itself. A favicon is only 16X16px, and so is harder to move. I think this should be WONTFIX.

"First off, this is an enhancement request."

Really sorry, that was one of my first times using this bug tracker. I didn't even see the "severity" field.

"Second, why should we not enable people to move the tab up or down? That is
standard FF functionality, and should not be removed."

Well, the functionality would be intact by using the favicon which takes us to the next point.

"Moving the Favicon is not very accessible in itself. A favicon is only 16X16px,
and so is harder to move. I think this should be WONTFIX."

As a user, I find the current behaviour TOO accessible, in that it has triggered by accident more usually than purpose. What's the use of dragging the tab to the browser to load it, anyway? Is it such a common action that justifies moving tabs more difficult?

I would rather be able to perform a common operation more easily (moving tabs) even if it implies making a less common operation (dragging to the browser) slightly harder.

I agree with this enhancement request. Having an obscure extra way to reload the page (or add a bookmark) isn't worth the annoyance for people trying to reorder tabs. And it will have to go away when we make it possible to drag away from the tab bar in order to create a new window, which I assume is what bug 225680 is about.

Bug 465346 will probably fix this (although I'm not exactly sure if it's a direct dupe). Specifically see Beltzner's proposal there about vertical sensitivity.

This works fine for me now. The tab doesn't detach unless there's a drag more then the height of the tabbar.

Yes, but that is not what this request it about.

It should have a graphical identity (e.g. "+") for creating a new window, and a perf to disable the behavior or adjust its threshold.

*** Bug 1369204 has been marked as a duplicate of this bug. ***

*** Bug 1357424 has been marked as a duplicate of this bug. ***

Created attachment 8902388
Bug 450915 - Increase the drag space of the TabsToolbar by 15px on the bottom to improve the tab reordering experience.

Review commit: https://reviewboard.mozilla.org/r/173956/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/173956/

Comment on attachment 8902388
Bug 450915 - Increase the drag space of the TabsToolbar by 15px on the bottom to improve the tab reordering experience.

https://reviewboard.mozilla.org/r/173956/#review179384

::: browser/base/content/browser.css:189
(Diff revision 1)
> + padding-bottom: 20px;
> +}
> +
> +#TabsToolbar[movingtab] + #nav-bar {
> + margin-top: -20px;
> + pointer-events: none;

This breaks dropping tabs on the bookmarks menu button

::: browser/themes/shared/tabs.inc.css:29
(Diff revision 1)
> :root:-moz-lwtheme {
> --tab-line-color: var(--lwt-accent-color);
> }
>
> #tabbrowser-tabs,
> +#tabbrowser-tabs > .tabbrowser-arrowscrollbox,

Why is this needed?

Comment on attachment 8902388
Bug 450915 - Increase the drag space of the TabsToolbar by 15px on the bottom to improve the tab reordering experience.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/173956/diff/1-2/

Comment on attachment 8902388
Bug 450915 - Increase the drag space of the TabsToolbar by 15px on the bottom to improve the tab reordering experience.

https://reviewboard.mozilla.org/r/173956/#review179384

> Why is this needed?

Without this, the tabs shrink in size from 33px to 29px (on Windows) with the increased padding-bottom.

Comment on attachment 8902388
Bug 450915 - Increase the drag space of the TabsToolbar by 15px on the bottom to improve the tab reordering experience.

Redirecting to Gijs who can hopefully get to this sooner.

Comment on attachment 8902388
Bug 450915 - Increase the drag space of the TabsToolbar by 15px on the bottom to improve the tab reordering experience.

https://reviewboard.mozilla.org/r/173956/#review182276

r+ with the downloads and home button included. We can followup making the 20px match the navbar height more exactly, and/or dealing with the menubar.

::: browser/base/content/browser.css:184
(Diff revision 2)
> .tabbrowser-tabs[movingtab] > .tabbrowser-tab[fadein]:not([selected]) {
> transition: transform 200ms var(--animation-easing-function);
> }
>
> +#TabsToolbar[movingtab] > .tabbrowser-tabs {
> + padding-bottom: 20px;

Clever. Two questions:

- the 20px feels kind of arbitrary. I guess this should basically be the navbar height, right? Is there some way we can more closely approximate this?
- should we also do the same for the top and the menubar, if the menubar is permanently visible (so on non-osx) ?

::: browser/base/content/browser.css:193
(Diff revision 2)
> + margin-top: -20px;
> + pointer-events: none;
> +}
> +
> +/* Allow dropping a tab on the bookmarks-menu-button to create a bookmark. */
> +#TabsToolbar[movingtab] + #nav-bar > #nav-bar-customization-target > #bookmarks-menu-button {

We should do the same for the downloads and the home button, which both also do reasonable things if dropping tabs on them.

::: browser/themes/shared/tabs.inc.css:29
(Diff revision 2)
> :root:-moz-lwtheme {
> --tab-line-color: var(--lwt-accent-color);
> }
>
> #tabbrowser-tabs,
> +#tabbrowser-tabs > .tabbrowser-arrowscrollbox,

Just for my (& future) understanding, why was this necessary?

Comment on attachment 8902388
Bug 450915 - Increase the drag space of the TabsToolbar by 15px on the bottom to improve the tab reordering experience.

https://reviewboard.mozilla.org/r/173956/#review182352

::: browser/base/content/browser.css:184
(Diff revision 2)
> .tabbrowser-tabs[movingtab] > .tabbrowser-tab[fadein]:not([selected]) {
> transition: transform 200ms var(--animation-easing-function);
> }
>
> +#TabsToolbar[movingtab] > .tabbrowser-tabs {
> + padding-bottom: 20px;

The more we increase this the harder it is to tear off a tab without making a large mouse movement. We're trying to balance ease of reordering tabs and tearing off tabs.

Chrome looks to tear off at about 15 pixes from their tab bar, even though their navbar measures about 35px tall.

Edge tears off around 8-10px, but their implementation treats reordering and tearing off pretty much as one-in-the-same.

Doing this for the top and the menubar isn't as straightforward due to the visibility of the menubar etc and didn't seem worth the extra complexity for a "nice-to-have".

I'll lower our amount to be closer to Chrome since we don't have a metric that says what is the *best* value here, and we don't want to make tearing tabs off too much harder.

::: browser/themes/shared/tabs.inc.css:29
(Diff revision 2)
> :root:-moz-lwtheme {
> --tab-line-color: var(--lwt-accent-color);
> }
>
> #tabbrowser-tabs,
> +#tabbrowser-tabs > .tabbrowser-arrowscrollbox,

This was answered in comment 14. Because of how -moz-box-align:stretch; is applying the space, the tabs shrink in size from 33px to 29px (on Windows default density) with the increased padding-bottom.

Comment on attachment 8902388
Bug 450915 - Increase the drag space of the TabsToolbar by 15px on the bottom to improve the tab reordering experience.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/173956/diff/2-3/

Comment on attachment 8902388
Bug 450915 - Increase the drag space of the TabsToolbar by 15px on the bottom to improve the tab reordering experience.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/173956/diff/3-4/

Pushed by <email address hidden>:
https://hg.mozilla.org/integration/autoland/rev/481d7cc2f6f0
Increase the drag space of the TabsToolbar by 15px on the bottom to improve the tab reordering experience. r=Gijs

https://hg.mozilla.org/mozilla-central/rev/481d7cc2f6f0

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 (20170915100121)

This issue is verified as fixed with the latest Nightly build on 9/15/2017.

*** Bug 802934 has been marked as a duplicate of this bug. ***