563540 - implement aero snap for torn off Firefox tabs

Status: NEW

(Firefox :: Tabbed Browser, enhancement)

Description

[Asa Dotzler [:asa]]

When I drag a Firefox window to the right or left side of my Windows 7 desktop, the aero snap feature (I think that's what it's called) allows me to dock the window to that side of the desktop at half desktop width, full desktop height.  When I drag a Firefox window to the top of my Windows 7 desktop, the aero snap feature allows me to easily drop to maximize the window.

I've recently started using this feature in a couple of my other apps and I think the reason I don't use it much in Firefox is that while it works for windows, it doesn't work when I drag a tab out of a window which I think would be my common use case.

Is this the kind of thing we could fix by making our dragged tab pretend to be a window so we get the feature for free or where we could fake it with our own window docking/tiling implementation?

Comment 1

[Asa Dotzler [:asa]]

I've added an MS doc to the URL which described the Aero Snap design process in case this helps clarify use cases or other questions.

Comment 2

[Benjamin Smedberg]

This sound nice but really hard... drag-target and window APIs are very different.

Comment 3

[Marco Bonardo [:mak]]

hm, I guess if it could be emulated when we open the new window, detecting how far we are from the border and sizing the window accordingly. Won't have the nice OS feedback though.

Chrome handles this a bit diffently, it works but not using the OS support, they have a sort of drag overlay and if you drop on the split buttons the window is sized accordingly to half of the screen.

Comment 4

[Jim Mathies [:jimm]]

A transition from the drag image to an actual semi-transparent or glass top level window during the drag would do it. I don't believe we have the ability in widget to set partial transparency on top top level windows, but I'm sure we could add it. We already have support for glass windows if something like that is more visually appealing.

I think basic support for this could be implemented up in tab browser, then we can add desired visual effects for top level windows in widget.

(In reply to comment #3)
> hm, I guess if it could be emulated when we open the new window, detecting how
> far we are from the border and sizing the window accordingly. Won't have the
> nice OS feedback though.

Based on past experience, hacks in widget to do things like this tend to cause more trouble than they're worth over the long term. We also need to keep in mind that tabs as widgets are likely going away.

Comment 5

[Marco Bonardo [:mak]]

Just FYI, an interesting shortcut in Windows 7 to use Aero Snap is [WinKey]+cursors, so while we wait for this to be implemented, dropping the tab (to a new window) and using the [win]+right shortcut is a quick workaround to snap to right.

Comment 6

[Christian Ascheberg]

IE9 can drag tabs into aero snap, and MS explicitly says that Firefox can not.
(btw: bug 485105 is about "improve tab-to-window experience")

Comment 8

[imradyurrad]

(In reply to comment #6)
> IE9 can drag tabs into aero snap, and MS explicitly says that Firefox can not.
> (btw: bug 485105 is about "improve tab-to-window experience")

Why can't Firefox?

Comment 9

[Paul [pwd]]

(In reply to comment #8)
> (In reply to comment #6)
> > IE9 can drag tabs into aero snap, and MS explicitly says that Firefox can not.
> > (btw: bug 485105 is about "improve tab-to-window experience")
> 
> Why can't Firefox?

Because Firefox hasn't been designed to work as such. IE9 pretty much creates a new window from the moment you leave the tab bar and thus of course you can snap windows. Firefox continues to create tabs as tabs you want to place up until you release the mouse button.

Comment 10

[Jim Mathies [:jimm]]

(In reply to comment #8)
> (In reply to comment #6)
> > IE9 can drag tabs into aero snap, and MS explicitly says that Firefox can not.
> > (btw: bug 485105 is about "improve tab-to-window experience")
> 
> Why can't Firefox?

We are in the process of adding support for this. If you step up the bug chain of bugs blocking this one you'll see what this depends on.

Comment 11

[Frank Yan (:fryn)]

Attachment: prototype v1

Here's a prototype patch created on top of patch v13 for bug 455694.

It attempts to hide the window of the tab being dragged if the tab is the only tab in that window. (This part is hacky, but the effect works really well on OS X. I haven't tested it on Windows and Linux yet.)

It maximizes the detached tab's new window when dropping a tab at the top of a screen on Windows, OS X, and Linux. (I don't know if we want this for OS X and Linux too, but it sure is useful.)

It "docks" the new window to the left half of the screen when dropping a tab at the left edge of the screen, and likewise to the right half when dropping at the right edge. This prototype doesn't use the Aero Snap API for this, because I'm not aware of the existence of a public API. Jim, do you know more about that?

Comment 12

[Frank Yan (:fryn)]

Attachment: part 1: maximizing WIP1

This patch just handles maximizing, since I don't think we should try docking to the left or right without using the proper API.

A final patch should include visual feedback that the tab will become maximized and detect the OS has Aero Snap. (Currently, the #ifdef only checks for Windows, not Vista or newer.)

Comment 13

[Yann Brelière]

(In reply to comment #11)
> It maximizes the detached tab's new window when dropping a tab at the top of
> a screen on Windows, OS X, and Linux. (I don't know if we want this for OS X
> and Linux too, but it sure is useful.)
In Unity (Ubuntu > 11.04), there is a feature similar to Aero Snap, so it would be great to have it if it's done for Windows. For the maximize when dragging on top of the screen, I believe it's even a common behavior on other linux desktop environments.

Comment 14

[Frank Yan (:fryn)]

Attachment: part 1: maximizing

As noted in comment 13, since Ubuntu 11.04 supports this "snap" feature, I've changed the #ifdef XP_WIN to #ifndef XP_MACOSX.

Comment 15

[Frank Yan (:fryn)]

Attachment: part 2: docking left/right PROTOTYPE

Prototype of "docking" left/right. Not using actual Aero Snap, so Win+Left/Right do not restore the window size.

I won't be working on this any further until we figure out a way to use the actual Aero Snap API.

Comment 16

[Javi Rueda :javirid]

(In reply to Frank Yan (:fryn) from comment #15)

> I won't be working on this any further until we figure out a way to use the
> actual Aero Snap API.

Maybe this could help to solve the underlying problem: http://stackoverflow.com/questions/2920451/aero-snap-not-working-for-my-application

It seems that the window should be created with the WS_THICKFRAME flag and then responding with a zero to the WM_NCCALCSIZE message in the loop. At least, I hope this serves.

Comment 17

[Johan C]

Nominating this for the firefox-backlog.

This is request for something that would be nice to have, as it is a useful feature. It would also be nice to be consistent with the OS (win7+) and other browsers. IE (from version 9?) as well as Chrome already support this.

Furthermore this is something that looks to be a highlighted feature in Windows 10 (with a bunch of improvements). Because this might come up in the future, implementing this into Firefox before Windows 10 might make further improvements in Firefox take less time and seem less daunting. Concerning consistency with Windows itself from the above paragraph, if Windows 10 were to (finally) add tabs to Windows Explorer, they might (hopefully) support snapping tabs.

Websites are becoming more and more advanced as browsers and web-technology matures. Some websites are already very advanced and comparable to native applications. It is therefore important that improvements are made to any chrome that is still necessary (in this case tabs), such as deeper integration with the OS.

This almost turned into an essay, sorry about that.

Comment 18

[Johan C]

This probably depends on bug 1019738. To trigger aero snap we probably have to drag an actual window to one of the trigger areas when detaching a tab. Unless we want to fake aero snap. I could be entirely mistaken of course, in which case feel free to correct me. :)

Comment 19

[jonathanbeaudoin1996]

This feature will be super helpful with the improvements of snapping in Windows 10. Almost all modern browsers has this functionality with the exception of firefox. Please implement this.

Comment 20

[chrisdeleonadmin]

As a user of PowerToys' Fancy Zones, and with Windows 11 further enhancing snap zones as a default feature, I'm feeling this is more of an S2.
I'm trying to switch to Firefox from Edge, and this missing feature is quite irritating, and definitely has me on the verge of switching back to Edge. Having a tool that you use more than any other tool behave in an unexpected manner is also flow-breaking. I was doing something else, but then I had the window-dragging issue, and now I'm here.

So... is there something I can do? I'm a junior dev, straight out of college, all my personal projects are hacky python scripts. But if I could be pointed to a particular pipe to bang on, I will happily do my best to help out. For now, I'm going to start digging through code, wrapping my head around how this whole tab system works, and see if I can't help with Bug 1019738 - Tab Detaching: remove and slide the tab out of the tabstrip when drag-detaching a tab

Comment 21

[Erich Gubler [:ErichDonGubler] (he/him)]

Fixing up a bitrotted link.