In most operating systems, there is a major distinction between:

  • interactions which are available only when the element is in focus (for example typing in order to write a text in a text field) and:

  • interactions which are available at any moment (for example clicking on a button).

Being able to click anywhere, including on a non-active window, is sometimes disturbing. In fact, windows on background are usually not entirely visible, and clicking on them would have a risk of interacting with the window itself, instead of bringing the window to the front.

For example, if Windows Live Messenger discussion window is covered by the browser so that only the bottom is visible, activating the window by rapidly clicking on it becomes a random process, since it is possible, by mistake, to click on a button with an irreversible effect, like Voice call (see screenshot), given that the button is:

  • not recognizable as Voice call button, since you don't see neither the icon, nor the text.

  • not recognizable as a button, since the border is not shown until the cursor is over it.

The screenshot shows Windows Live Messenger window with its Voice call button. The window is covered by browser's window.

The alternative to the default behavior of being able to interact directly with inactive windows would be to disable elements on inactive windows.

  • The advantage would be that instead of pointing precisely on a non-interactive zone of a window (here, the small zone between the bottom of the window and the buttons of Windows Live Messenger), the user would be able to click anywhere on an inactive window to activate it.

  • Another advantage is that there is no confusion in the click action. Currently, depending on the state of the window, a click on a button may either start the button click event (if the window is already active), or both activate the window and start the click event (if the window was not active).

  • The problem is that it requires two clicks to interact with a window in cases where the goal is to interact with a well-visible element of a window. This is often the case when working with two applications or documents, side by side.

  • Another problem is that the visual response (disabled button) wouldn't be clear for sure: is it disabled because you can't interact with it, or because its window is inactive?


  1. What may be the implications in terms of user efficiency, if any element of a window were disabled when the window is inactive?

  2. Are there applications which are actually disabling their controls when becoming inactive? Were their approach considered ineffective, UX-wise?

  • 3
    When considering efficiency you have to note you're also adding a click to every possible cross-window action, which can add up quick
    – Ben Brocka
    Nov 7, 2012 at 19:42
  • OS X actually tackles this issue nicely; Seeing as windows are effectively stacked upon one another, clicking on an inactive window (accidental or not), then activates that window and brings it to the foreground. This process then, avoids any unwanted actions such as selecting a button or inputting text etc, as the initial click only serves to activate the window. Nov 7, 2012 at 19:47

2 Answers 2


There are two different parts to your question.

The first is whether it's more efficient to disable controls in inactive windows. I'd suggest that it isn't, because disabling a control means that it has no content worth the users attention - disable != readonly. In most cases a background window does have content the user may want to reference, concealing that information would make things much harder to use.

The second is whether it's a good idea to "swallow" the first click on a window, so that users don't inadvertently activate things they may not want. I think this is a great idea - and so does Microsoft (well, the Office team, anyway), as Microsoft Office does this throughout.

Try overlapping a Word or Excel window with other windows and see what clicking on the Office window does - doesn't matter where you click, it just activates the window. More applications should emulate this approach, IMHO.

  • I haven't noticed before that Microsoft Office applications were ignoring the first click. Great example. Thank you. Nov 8, 2012 at 1:24
  • I actually find Office's "swallow first click" behavior very frustrating. I have an Excel report with hyperlinks in one column, and I place the browser side-by-side with Excel. When several consecutive items require no action, my interactions are: click link in Excel, review target in browser, close browser tab, click next link in Excel. In this process, the extra click each time really adds up over the whole report. And a colleague of mine, who isn't as used to this quirk as I am, often waits quite a while before realizing that her explicit button click on an inactive window did nothing. Jan 18, 2016 at 18:21

Great question (especially the part about accidentally clicking on an action button when selecting the inactive window).

I think it makes sense to disable/grey-out the inactive windows (the ones that are not currently receiving the user's input (mouse, keyboard and most importantly, attention) ONLY if they are overlapping each other even if it's just by a few millimeters. So the user knows just by looking at the partial view of the window behind the current active window, that it's disabled since it will look disabled with greyed-out icons and buttons and text, etc.

So clicking on the inactive window (anywhere on the window should work since the buttons & content are all disabled) will serve only one purpose - bringing it to life and then on it shall be the active window.

I must acknowledge that it would be an interesting programming challenge to detect if the windows are overlapping in the screen but it's certainly doable.

This way if the user is trying to work with two applications/windows side by side, they wouldn't have to click twice to activate one or the other.

Hope that helps.

  • isn't overlap check the same as a simple overlapping rectangles check done in the windowing system? Nov 8, 2012 at 9:07

Your Answer

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

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