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.

This feature is already implemented.

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.

See bug 552982 Displaying a titlebar is quite simple, but complications arise due to the manner in which views and widgets are positioned that cause coordinates to be calculated incorrectly and the popup to jump about the screen.

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'.

One potential complexity here is that on Mac, the window close button is implemented via two callbacks, one to ask to close and the other upon closing. This means that the manner in which popuphiding and popuphidden events need to fire may need to be changed to accomidate this.

See bug 554928.

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. More details on dockable panels.

Docking is pretty simple, but implementing docked titlebar UI and a dock button on the undocked panel titlebar is more difficult. See bug 554926.

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.

This feature is already implemented but should have a separate attribute to control it. See bug 554925.

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.

The 'parent' and 'top' levels are already implemented.

Visible per tab/window/application

The panel is only visible when its associated tab is focused, when a window is active or when any window within the application is active. It may also be desirable to have a window only visible when a certain type of window is active. The latter feature of being visible only when the application is active is a built-in feature on Mac. Examples are the font and color picker panels.

Background drag to move

The panel can be moved by dragging its background, whether there is a titlebar or not.

See bug 554919. This is fairly simple to implement and could be done simply by modifying WindowDraggingUtils.jsm.

Arrow to the panel's anchor

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)

This would involve implementing an event or callback when a popup is properly positioned and sized so that the arrow could be positioned to match. See bug 554937.

Fade in and fade out

not as visually noisy as the next feature, and 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.

For this and the previous feature, it would be ideal to have a means of setting animated effects when a popup is shown or hidden that work more automatically. This will need underlying work. Implementing this should also allow for an easier way to implement the Mac-style flash when a menu item is selected.

Resizable

I'm conflicted on if we would actually turn this functionality on for some of the Firefox panels, but it is nonetheless probably an important feature of the general purpose widget. See bug 418864 for all the hate mail on the bookmarks panel not being resizable.

This is already implemented by using a <resizer> in a panel.

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.

It's unclear if this is even needed or should be supported. Once the other basic features are in place, we can examine what is needed here. Much of how this should and can work relies on the underlying platform support.

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.
• Since extensions may commonly use panels for notification, should we have some type of standard "notification panel" that takes an icon, a message, and an action/actions and handles the layout to match all of the other instances of panel-based notification?

Focus Issues in Panels

A number of platform-specific focus related problems exist with panels. Child frames (<iframe> elements for example) should be avoided in panels, mainly due to the mouse not functioning in them on Windows. In addition, noautohide panels have significant problems on Linux. The following summarizes these issues with panels on each platform.

Note that the issues listed below are mostly now fixed.

Mac

• mouse and keys works ok in popup parent and child
• issue: mouse click propagates to parent button when <button type="panel"/>
• issue: if another window is currently focused, clicking somewhere in the panel raises, focuses and activates what was clicked immediately instead of just raising the window

Windows

• mouse and keys works ok in popup parent
• mouse works ok in child
• issue: keys do not work in child
• issue: tabbing between parent popup parent and child causes the titlebar to flicker
• issue: sometimes, clicking the mouse in child causes the parent to flicker
• issue: sometimes, clicking the mouse in child just causes the previous focused element to be focused. Effectively, as if the popup was just being raised.

Linux

• for normal panels, mouse and keys works ok in popup parent and child
• noautohide panels:
  • issue: mouse works in popup parent and child, but focus is not set on the element
  • issue: keys do not work in popup parent or child
  • issue: parent window loses active state when the panel is opens
  • issue: parent window loses active state when the mouse is pressed in popup parent or child
  • if the parent window titlebar is clicked, the window becomes active and keys work ok in the popup parent and child again, but a mouse click will cause the active state to be lost again
  • issue: minimizing the window and restoring causes the element in the popup parent or child to look focused, but keys still don't work