Asynchronous opening of windows
Contents
The problem
Most window systems allow processes to open windows asynchronously, i.e. not in direct response to an action taken by the user such as clicking a mouse button.
Practical problems with non-malicious programs
Starting an application from a Start menu can take tens of seconds if the program is big and has to load a lot of data from disc or the system is heavily loaded. After this delay, the window pops up. During this delay the user has the choice of waiting or trying to get on with another task. If the user does the latter, the task might get interrupted when the application pops open its window. To avoid this annoyance, the user might choose simply to wait, making this delay "dead time".
Security problems
Stealing input focus: The user is entering a password. Another process pops up a window, acquiring the input focus, and it receives the password.
Denial of service: There is typically no limit on the number of windows a process can open or the rate at which it can open them, so it can deny service by opening a lot of windows.
The Javascript pop-up and pop-behind problem is an example of this issue. The problem is firstly that the Web browser is given the authority to open windows asynchronously, and secondly that it passed on this authority to the Javascript code it executed.
Partial solutions
A partial solution is not to allow a process to open a window at the top of the stack if the user appears to be interacting with another process's window (e.g. if the user has recently clicked on or typed into that window). Instead, the new window is opened behind the current window and the new window's taskbar icon is flashed.
This appears to be implemented by Windows XP and by Metacity under X.
This is only a partial solution because it is heuristic: it has to guess whether the user is currently interacting with a window. It cannot always predict the future: the user might be just about to click on the current window when the new window is opened on top of it.
Metacity's heuristic gets things wrong sometimes: When a FilePowerbox is opened, it sometimes gets put behind the application's window. This probably happens because the dialog box window and application window are owned by different X clients.
Synchronous window opening
In this scheme, processes must declare in advance to the window system what user actions can open windows (see TrustedPathButtons). For example, the process can declare that clicking in a specified region of a window with a particular mouse button will open a window of a specified size (possibly specifying its initial title as well). When the user clicks in that region, the window system will open the window on the process's behalf. This would be the only way to open new top-level windows.
When one program, such as a Start menu, launches other applications, it is now the responsibility of the launcher to specify the sizes of the windows that get opened rather than the responsibility of the individual applications. However, the launcher can query the applications in advance to find out their preferred initial window sizes.
Asynchronously-opened windows start off as subwindows
In this scheme, if a process asynchronously opens a new window, the window initially appears as a subwindow of one of the process's existing windows. Clicking/dragging on the new window's title bar (and maybe inside it) promotes it to the status of top-level window, and adds it to the taskbar. While the new window is only a subwindow, it is given a different colour title bar.
This would work well for small dialog boxes that are opened from large windows. It would handle Javascript popups from Web browsers well. It would not be so good for applications that start off with small windows.
If an application has multiple top-level windows, which is used as the parent of the new window? This may have to be determined heuristically.
Closing windows
We might want to prevent processes from asynchronously closing their windows as well.
History
I first articulated this idea in July 2001 in a post on the e-lang mailing list.
Possible implementation
Add new window manager hints to a window W:
_WM_PARENT=P: This means that window P is the parent of W. Window W, when opened, will become a "provisional window", initially displayed as a subwindow of P.
- This property is only read by the window manager at the time when W is mapped, so changing it does not reparent window W.
_WM_REPLACE=P: This means that window W takes over window P's frame. This means a new window can be opened quickly, and can later be replaced by a slow-to-start application.
- Window P should get an unmap event when the replacement occurs. The two windows will no longer be connected after that point. This means that the client owning window P no longer needs to keep track of the window.
The two hints can be used together:
Client A opens a subwindow with _WM_PARENT.
Client B replaces this window with _WM_REPLACE.
Instead of _WM_REPLACE we could have:
_WM_PLACEHOLDER: This declares that this is a placeholder window, and the first window opened as a child of this using _WM_PARENT should instead replace the window. This raises the question, what happens if two windows are opened as children?
This is best implemented in the window manager because it already knows about window positions, how to render frames, etc.
_WM_REPLACE should be easy to do in a window manager. We could do it independently, but it would involve a level of indirection.
_WM_PARENT would be difficult to do outside the window manager. We could provide our own window manager that uses OverrideRedirect windows and draws its own frames, but this would not interact with stacking, multiple desktops, etc. Our provisional windows could be framed outside the window manager, but turning these into WM-managed windows (when the user interacts with them) would be hard.
Related work
X startup notification protocol
See the Startup notification protocol spec. This protocol provides a way for one process to declare that it is starting an activity which may be slow to run and which may open a window. Window managers appear to use this to add an icon to the task bar while an application is starting (even though the icon does not correspond to a window). It is used to change the pointer to a "busy" shape.