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?

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.

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

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.

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.

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.

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")

(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?

(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.

(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.

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?

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.)

(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.

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

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.

(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.

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.

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. :)

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.