Take a simple dialog window: enter image description here

The user will expect that the titlebar can be used to drag the window through the screen. But why is it limited to just this bar?

Why is it uncommon that windows can be moved by clicking anywhere in the window that isn't an input element and just drag from there?

  • 4
    It's usually best to use "grips", little textured sections for users to drag on.
    – Ben Brocka
    Jul 17, 2014 at 18:40
  • 24
    After playing some PC games with "grab anywhere" windows, I can say that I do not enjoy such a UI "feature". I prefer having the grab & drag limited to the title bar of the dialog. There have been far too many times where I tried to interact with something in the dialog, and accidentally moved it instead.
    – Brian S
    Jul 17, 2014 at 19:07
  • 10
    Depends on the operating system and the desktop environment. On Unix-like systems (Ubuntu, OS X, etc) - you can usually press ALT and grab a window to drag it at any point. Additionally, Ubuntu usually breaks away from the traditional titlebar design and incorporates more interesting elements into the top area (GTK as a toolkit, and especially with Wayland around the corner, windows are going to become generally much more up the the application and will include even more various GUI elements where traditional titlebars use to be).
    – jcora
    Jul 17, 2014 at 20:24
  • 3
    It sounds as if you're on Windows and want to be able to drag windows more conveniently. Have you by chance heard of "AltDrag"? It's a tiny tray app which implements the unix-style "Alt"+"leftmousebutton" to move and "Alt"+"rightmousebutton" to resize. I've been using this on my windows machines ever since I started with bsd/linux many years ago, but am not otherwise affiliated with the product.
    – KlaymenDK
    Jul 18, 2014 at 9:00
  • 1
    This is not a satisfying answer but it might be worth noting, from a programming perspective, the fundamental design of Windows' event system means that application developers do have to take extra steps to make the window movable when the client area is dragged (even if the system, as designed now, handled client area drags in this way by default the API is such that it would be very easy for applications to break this behavior). The borders and title bar are by default managed by the system not the application (there are plenty of exceptions of course, which actually annoy me to look at).
    – Jason C
    Jul 18, 2014 at 14:59

8 Answers 8


I would say that this often leads to an unwanted drag and drop action. What if this window for example has a small scrollbar, you want to scroll to the bottom of the page and you accidentally miss the scrollbar? You would drag the window down and you might need to reverse this action.

Why is it uncommon that windows can be moved by clicking anyway in the window that isn't an input element and just drag from there?

Often there are images and other elements that you want to drag and drop to another window. Then you must be able to copy the label when you click near it but you also want to drag the window when you click far enough. So you need to define a place where every user can expect the window drag to work. And this currently is the title bar.

  • You could even imagine new behaviours that cope with the drag-window action, for example the scrollbar could enlarge when you get your mouse close to it, so this is unlikely that you misclick. I have worked with windows pen-tablet and this is a pain to select this scrollbar with a pen-tablet because it is so small.
    – Leths
    Jul 17, 2014 at 15:40
  • 1
    The problem with the right mouse button is that it's used for context menus, and might result in accidentally nudging the window when you just wanted a menu.
    – trlkly
    Jul 18, 2014 at 0:41
  • @trlkly you are right. But as an implementation detail it would be possible to respect this possibility and to not drag the window directly but with a little delay and only if you hold down your right mouse button longer than a click for context menus would take you.
    – Marvin
    Jul 18, 2014 at 7:34
  • 1
    +1 Another issue is frustration while learning, or inconsistencies between applications. For example, say application A displays an image which you can drag, but application B has a similar interface but no drag functionality. I can very easily imagine frustration on the part of a user using B who normally uses A accidentally dragging the window when they make the mistake of trying to drag the image. Same with a user using an application for the first time and thinking "Hm can I drag this?" With the exclusive title bar target, you always know what you are going to do.
    – Jason C
    Jul 18, 2014 at 14:52
  • edit: Dragging the window by holding your right mouse button could work! No, some applications like MS paint (gag) use the right button while dragging. Paint uses the right button to draw with the background color. As far as a little delay, that will only make it harder to use if the user wants to move it a few extra pixels and I've seen people hold the right click button for 2-3 seconds. The best thing IMHO would just be a bigger title bar with a little margin that it registers as dragging when you're "close enough." Jul 18, 2014 at 18:18

The title bar isn't always the only spot to that can be used to drag the window, (these days some windows can be dragged by parts of their background, but it's rare) but it's the oldest and most established and common convention. It originated in the early WIMP UIs, the Smalltalk systems from the 70s and 80s.


If you study the way the above windows were designed you'll see there really isn't any other affordance on a window for dragging it other than the title bar - there's no unused window background that could be grabbed (remember screen real estate was much more expensive back then). Soon the title bar became extended across the whole width of the window, making the window rectangular shaped, providing more space to grab and made screen updates computationally more efficient. And making the title bar full width allowed it to hold buttons that act as window manipulation shortcuts.

This turned out to be a very learnable, usable system and was copied by many different UIs (Mac, Windows, etc.). There wasn't any good reason to go away from this convention. It wasn't broke so there was no need to fix it, and it still survives today.

  • Glad to see this classic screen shot make its way back into modern conversation. It's been a while!
    – Jason C
    Jul 18, 2014 at 14:55

This is actually not always true. In some cases the default behavior of most apps would be to allow to drag windows by empty space. An example is KDE. See the screenshot:

enter image description here

KDE's default Oxygen widget style has window decoration visually merged with window contents. Thus, to make feel match look, the theme also by default allows to drag windows from all empty areas. Both parts of design are somewhat configurable: drag window option is highlighted in the screenshot — it can be disabled or minified, and there's also an option to outline active window title to prevent merging of decorations with content.

But this feature is a source of controversy between some users and developers, not only because of mistakenly dragging the window instead of moving a widget handle, as mentioned in Marvin's answer, but also because it is next to impossible to implement perfectly with current widget toolkits like Qt and GTK+. For GTK+ (in oxygen-gtk) there're quite some hacks including blacklisting some common applications and individual widgets from triggering drag operation. Similar hacks, though to a lesser extent, are present in oxygen-qt.

  • And I'm using a window manager that, if I hold the super key on the keyboard (aka the "Windows" key), the left mouse button can drag any window from anywhere in the window
    – Izkata
    Jul 17, 2014 at 18:50
  • 2
    -1 Doesn't as much answer the question as combat the statement “Why is it uncommon”. OP is clear that there are examples of software that implement windows that are indeed draggable. Jul 17, 2014 at 19:37
  • @SlippD.Thompson it's not that some individual piece of software that implements draggable windows. When Oxygen is in use with default settings, all the Qt4 and GTK+2/3 applications (except blacklisted ones) have this behavior. And these are the majority of GUI applications on modern open-source UNIX-like systems. They don't themselves do anything special to achieve this effect. So I'd not say it was clear from the OP.
    – Ruslan
    Jul 18, 2014 at 18:09
  • Oxygen isn't software? Again, the OP's question isn't “is this common?”, it's “why is it the way it is (most of the time)?” You're combatting the assumed premise of the question, not answering it. Jul 18, 2014 at 19:01
  • I have the impression that KDE will just build a cartesian feature matrix and implement everything in it.
    – msanford
    Jul 18, 2014 at 19:19

The Windows OS provides the (optional) title bar and control box, as well as a mechanism for OS users to organize their application windows (re-positioning, minimizing, maximizing, closing).

From the perspective of the Windows OS, the title bar is the user's API for these operations. Everything else in the window is "content" that is under the control of whoever developed that specific application.

The developer of the specific application may provide additional ways for a user to do re-positioning, minimizing, maximizing, and closing, by creating controls that trigger the API programmatically (i.e. you could implement an application where the windows could be re-positioned by dragging the background of the content). The developer may also switch off the title bar API entirely. It is their application. The OS can't impose re-positioning by dragging inside the content area, simply because it is (by design) outside their control.

  • 2
    Makes sense: The title bar is OS-level UI for OS-level tasks, (nearly) the rest of the window is app-level. And apps (from a UX perspective, not programmatic) have little-to-no jurisdiction over the positioning their windows across the screen(s). Jul 18, 2014 at 19:06

Dragging is limited to the title bar for consistency and perhaps usability. If you could both drag a window by clicking in the content area, as well as interact with buttons, text, etc. in the content area, there would be a much higher margin for error (and presumed difficulty in programming).

Clicks within the window are reserved for interacting with content. In your sample dialog window, there is ample whitespace to click and drag if that option existed. However, lets say you wanted to copy an error message from a window similar to what is below. Copying the message will allow you to paste it into a Google search and get more information in an attempt to solve the issue. It may be very difficult to copy the error if you could also drag by clicking in the main content area.


download bmml source – Wireframes created with Balsamiq Mockups

  • I disagree. I see text element as a manipulable element, so it should not trigger the drag-window action. I think the question is very valid and as you said it has not been done because there are difficulties for programming this, and the correct behaviour is to be defined. Presumably there are a lot of exceptions and use-case to think about before putting the drag-window into white-space, but I have used some draggable modal popup that do have this behaviour. It feels good
    – Leths
    Jul 17, 2014 at 15:28
  • It works fine with interaction only on the title bar because it has become convention. Intuitively, grabbing some white space with absolutely no content inside could lead to the drag-window action, and I believe it could be a good UX. But again it depends on your window. In the example given with the question, I feel like it is do-able and even desirable. I wish I could test this with completely computer-naive users
    – Leths
    Jul 17, 2014 at 15:37
  • @Leths I do agree that this is very context/content specific, especially for modal windows. However, I see another advantage for the title bar drag (in the example given with the question) in that the dragging area is positioned with the three other icons that control the window. All window controls are grouped above the content, paired with the name of the window itself.
    – Andy
    Jul 17, 2014 at 16:06
  • 5
    It's probably better to use the "most common" (expected) behavior (restrict drag-window to the title bar) rather than expecting users to learn a general rule ("click and drag anywhere to move the window") and then a whole bunch of exceptions: "clicking on an input won't work. Don't click on a scrollable map. Doesn't work here, doesn't work there...". It's even worse if it varies from window to window within an application. Stick to nice and simple -- and expected.
    – Phil Perry
    Jul 17, 2014 at 16:53
  • @Leths So for this multi-line message, how would you decide which areas are draggable and which aren't? Either you make the non-drag zone the rectangular bounding box of the text (cheaper, but non-intuitive and inconsistent since it makes some empty space non-draggable), or only block dragging the actual text area (consistent, but a more expensive check)? Keep in mind all the major GUI APIs (Windows, Mac OS, X) date back to the early '80s when MBs of RAM and CPU MHz were both measured in the single digits.
    – nobody
    Jul 17, 2014 at 18:28

There's quite probably also a historical reason: defining whether the cursor is in the title bar is computationally a much simpler problem than defining whether it is in NOT(text OR button OR input box OR scrollbar OR ...). I think I remember draggable windows in GEM on a machine bought in 1987 with 512kB of RAM, and certainly in some DOS applications (text mode) from a few years later. In both of these cases code had to be kept simple. Without a compelling reason to change this convention it stuck. You could even suggest that some of the other reasons in the other answers follow on from this long-standing behaviour, as windows became more complex. That might be going a little too far though.

  • 1
    Not just a code-side "is this an interactive element", but a UX-one too. Take this page you're looking at: can you tell me which parts are 100% guaranteed to be entirely uninteractive? Jul 18, 2014 at 1:15

The question is mostly moot because, even where dragging on empty space is an option, nobody sits there choosing a spot to drag from. That would take longer than moving the mouse straight to the one place you know will work.

In terms of quickly acquiring a draggable area, I think it has more than zero value. But if it's not consistent it's not useful, and it seems like the only way it could be consistent is if windows had thick borders all round; and in that case, the borders would anyway be more useful as resize handles than drag handles.

Anyway, I'm not convinced there is a performance penalty to draggable empty space. When you click with the mouse, the system (OS + applications) has to search through every control on the screen to make sure it has found the correct target for the click. By the time it has figured out that your click was not inside any controls, it doesn't cost anything extra to say "OK then, start dragging the window".


Mac OS X allows dragging by window content. All windows that were "brushed metal" worked this way. So the whole window body was a draggable area, and only areas occupied by actual controls weren't draggable. The problem with this approach (at least for me and some friends) was that it was not quite clear to users where one could drag and where one couldn't.

This is exacerbated if you have views that do not have an obvious border. As the drag area was generally specified per view, the non-draggable area was always a rectangle around a view, even if its graphics were circular, or if some parts of the view were thinner than others.

It seems Apple has noticed this, as the general look of "brushed metal" has been removed (though windows created as such still allow dragging, they just don't look that different). However, windows like Safari browser windows or Messages buddy windows still let you drag them e.g. by their status bars at the bottom. So there seems to be a development towards making only clearly delineated areas without borderless UI elements draggable these days.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.