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 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?
Questions:
What may be the implications in terms of user efficiency, if any element of a window were disabled when the window is inactive?
Are there applications which are actually disabling their controls when becoming inactive? Were their approach considered ineffective, UX-wise?