Closed Bug 450915 Opened 11 years ago Closed 2 years ago

Dragging a tab (slightly) outside of the tab bar should still just reorder the tabs

Categories

(Firefox :: Tabbed Browser, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 57
Iteration:
57.3 - Sep 19
Tracking Status
firefox57 --- verified

People

(Reporter: frandavid100, Assigned: jaws)

References

(Blocks 1 open bug, Regressed 1 open bug)

Details

(Keywords: ux-control, Whiteboard: [reserve-photon-animation])

Attachments

(2 files)

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.
Attached image 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.
Severity: normal → enhancement
Summary: Handle tabs like other gnome apps → Dragging a tab (slightly) outside of the tab bar should still just reorder the tabs
"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.
Assignee: nobody → mano
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Depends on: 471499
Resolution: --- → FIXED
Whiteboard: [fixed by bug 471499]
Yes, but that is not what this request it about.
Assignee: mano → nobody
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Whiteboard: [fixed by bug 471499]
See Also: → 1369204
It should have a graphical identity (e.g. "+") for creating a new window, and a perf to disable the behavior or adjust its threshold.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: ux-control
OS: Linux → All
Hardware: x86 → All
See Also: 1369204
Duplicate of this bug: 1369204
Depends on: 674925
Blocks: 1352117
Severity: enhancement → normal
Flags: qe-verify+
Priority: -- → P4
Whiteboard: [reserve-photon-animation]
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Iteration: --- → 57.3 - Sep 19
Priority: P4 → P1
Comment on attachment 8902388 [details]
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?
Attachment #8902388 - Flags: review?(dao+bmo)
QA Contact: jwilliams → stefan.georgiev
Comment on attachment 8902388 [details]
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 [details]
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.
Attachment #8902388 - Flags: review?(dao+bmo) → review?(gijskruitbosch+bugs)
Comment on attachment 8902388 [details]
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?
Attachment #8902388 - Flags: review?(gijskruitbosch+bugs) → review+
Comment on attachment 8902388 [details]
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.
Pushed by jwein@mozilla.com:
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
Status: ASSIGNED → RESOLVED
Closed: 11 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Depends on: 1398230
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.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Depends on: 1400556
Duplicate of this bug: 802934
Depends on: 1511053
No longer depends on: 674925
Regressions: 1542353
You need to log in before you can comment on or make changes to this bug.