XUL:Panel Improvements

Panel Improvements

Currently, three types of floating popups are supprted, menupopups, panels and tooltips. Menupopups and tooltips have a specific purpose and isn't part of the descriptions below. Assume they work as normal.

Panels have a number of uses. Currently, they are intended as temporary floating popups to interact with a few controls and then it goes away. The user isn't expected to interact with the rest of the application until they are finished with the panel. The panel goes away if the user presses Escape or if the user clicks outside the panel.

The 'noautohide' feature provides a somewhat different purpose. When enabled, by setting 'noautohide' to true, it makes the panel more permanent. It only disappears when the application requests it by hiding the panel via script. The application could provide a close or cancel button in the panel that does this.

A window is distinct from a panel. A window participates in normal window ordering with other windows and other applications. Clicking on a window raises it to the front. In addition, a window appears on the taskbar, the list that appears on Alt+Tab and so on. A panel, on the other hand in expected to be a helper subwindow for another window. It does not appear in any operating system window lists such as the taskbar. Normally, a panel will float above the main window.

The idea here is to improve panels with additional features found in other typical application.

Desired behaviours of panels:

Close on outside click/escape key: When clicking outside of a panel, or pressing the Escape key, the panel will be closed. This is currently controlled via the noautohide attribute, which can be set to either true or false. The default value is false, which makes the panel close in this way. If true, the panel will only be closed if a call to hidePopup is made.
Titlebar: By default panels, do not have a titlebar. Support is desired for both normal size and thin titlebars. When a titlebar is present, the panel can be moved around by dragging the titlebar. The titlebar can optionally have a label. This is possible via a new attribute titlebar which can be set to false (the default), 'normal' for a normal titlebar or 'thin' for a thin titlebar. The titlebar attribute has no effect unless the noautohide attribute is set to true.
Close button: A close button, off by default, to close the popup. A new attribute, closebutton, set to either true or false. Has no effect if the titlebar attribute isn't set to 'normal' or 'thin'.
Dockable: A dock button on the titlebar to dock the panel into the main window. It would appear as, for example, a sidebar. Events would be needed when a panel switches between these states to update any UI that might be different. For instance, while a titlebar might appear while docked, it won't be a native titlebar, although some platforms may be able to render it as such. In the future, drag and drop of panels to dock them may be an option. A dockbutton attribute would put a button on the titlebar to dock and undock the panel. The attribute would have no effect if a titlebar wasn't present. An API should exist to dock and undock the panel; this would ideally work even if the button wasn't present.
Moves with its parent: A panel can optionally maintain its position relative to its parent window, when the parent moves. This also implies that when the main window is minimized or restored, the panel minimizes or restores as well. Currently, this behaviour is implied when noautohide is set to true, but it would be better if this would independently adjustable. A new attribute dependent can be set to true or false, where false is the default.
Window level: Control over the window level of the panel. Three levels are desired, a panel which floats above all windows (including those of other applications), a panel which floats above only its parent main window, and a panel that participates in the normal window ordering. The 'level' attribute currently exists to control this, set to either 'top' or 'parent'. The default value is platform specific.
Only visible when main window active: The floating panel is only visible while the main window is frontmost. If another window is made active, it disappears. It reappears when the window is made frontmost again. It may be desirable to have this only disappear for any window of the same application or of a certain type.
Independently focusable: The panel can be raised and focused independently of its parent main window. When this happens, the main window loses its active status (its titlebar becomes inactive). In some cases, it is only needed when certain elements in the panel become focused. For instance, a panel that contains a number of tool buttons and a textbox doesn't need to focus when the buttons are clicked, but only when the textbox is focused.
Background drag to move: The panel can be moved by dragging its background, whether there is a titlebar or not. This could be done with <titlebar> or WindowDraggingUtils.jsm.
Arrow to the panel's originator: For panels that are click outside to close, it is important to establish what target created the panel so that it can be accessed again. This target also serves in some ways as the panels "title" (although in more of a visual sense). For instance the current bookmark panel draws a half diamond to the star icon that creates it. The location of the half diamond needs to change based on where the panel is drawn. (moving the Firefox window to the far bottom of the screen and clicking the star demonstrates the current problem)
Fade in and fade out: not as visually noisy as the next feature, works particularly well with partially transparent panels that are click outside to close
Animation showing panel's originator: Applications like iCal and google maps on the iPhone have a nice animation where the panel grows out of the thing that creates it, gets a little bit too large, and then springs back to the correct size. The result is an interface that feels very dynamic, bouncy and happy.

Planed Future Use of Panels in Firefox

This is a tentative list of how we may use panels in Firefox's UI in the future:

[currently in use] Bookmark properties
[currently in use] Site identity
Context menu on hyperlink > "Bookmark This Link"
Context menu on bookmark > "Properties"
Notification of site level events (password manager, geolocation, popups blocked, xpi install, etc.)
Download progress (Limi is the main contact, he'll post details soon)
Items on the extension bar, both jetpacks and converted traditional toolbars (Boriss is the main contact)
Test pilot notifications from the extension bar, not technically part of Firefox but nonetheless a good example of extensions using panels for parts of their UI.

Random Thoughts

Should we automatically set the transparency level if the panel is set to click outside to close? We are currently doing this for the custom panels in Firefox for bookmarking and identity on OS X, so that they appear light and ephemeral. We were going to do it on Windows as well but ran out of time right before shipping. (Linux is I believe still blocked by bug 408284
We need to figure out the correct default appearance for each platform. The tool tip appearance being used on Vista wasn't entirely intentional. Should have shorlander think about this.