Labs/Tabframe

From MozillaWiki
Jump to: navigation, search

"Tabframe" user interface proposal

The "Tabframe" feature would allow a pinned page to display information to a user when the page's tab is not active by controlling both some space in the page's tab and a flyout/overlay.

tabframe.png

tabframe2.png

The display space, which we call the "frame", would be the same height as the tab, and grow horizontally up to some browser-enforced maximum. The display is implemented as an iframe loaded from a URL specified by the pinned page. It has access to the same layout, styling, script, and network capabilities as a normal DOM; see "Limitations on the tab frame's capabilities", below, for ways in which it differs.

The tabframe may display a "popup" panel, which is vertically pinned to the tabframe, and contains a full DOM window, which supports keyboard, mouse, and touch interactions. Multiple interactions are allowed in a flyout (i.e. not just one click) and interactions in the flyout can cause changes to the pinned page, or trigger a new load on the pinned page.

When the user interacts with the frame while the currently-displayed tab is not the pinned page, the frame can present the popup without refocusing the browser to the pinned page. The popup may use a focus() API to bring the browser focus back to the pinned page.

Interactions from the Pinned Page

The main page initializes the "frame" and "popup", it can interact with the two as if they were iframes, i.e., it has references to the window objects of "frame" and "popup". Similarly, these children pages have a reference to the main page, e.g., window.parent or window.opener. And just like iframes on a page, if the main page navigates away, the children "frame" and "popup" would also go away.

Setting the frame size

The page would need to specify how much space should be rendered for the "frame" area. Potentially the "frame" page could read the maximum dimensions through .clientHeight and .clientWidth, and adjust its layout, but the page still needs to either specify how much space to use perhaps either by directly providing some offsets and sizes, or the page can explicitly/implicitly specify a DOM node.

API: get/set dimensions of "frame"

Dynamically updating the frame

This should be doable with the iframe-like interface where the main page is already getting updates, so now it would just need to pass the message on to the "frame" window either with direct modifications, function calls, or postMessage.

Frame interactions that open a popup

The "frame" can handle mouse events and change the contents of "popup." There needs to be a way to control when the popup is shown as well as what should be shown. Positioning could be handled by the browser putting it just underneath the page's tab. Just to note, this popup would not be another OS-level window and would render within the browser window.

API: get/set visibility of "popup" API: get/set dimensions of "popup"

Multiple interactions within a popup

The "popup" detects mouse events to make background requests to the server without navigating away just like how the main page handles it now.

Loading a page in response to clicks in the flyout

The "popup" can control the main page to handle navigation, which would do the iframe/update content pattern as opposed to changing the top-level navigation. This would need some way to make the main page's tab active again. The popup should probably automatically hide when switching to the tab.

API: get/set activeness of the main page (to switch to it)

Initializing the frame and popup

There are a couple ways we could do this. Declaratively, the page sets a META tag. Programmatically, the page calls a new JavaScript API -- perhaps in response to a "pinned" event.

The other question is, should the page explicitly provider provide two URLs (one for "frame" and another for "popup") or perhaps just one URL or event none at all. With no URLs, the children would start with the current page's URL, and when a child page loads, it can check window.parent's reference to "frame" or "popup" to handles its behavior.

Looking for feedback

Initial feedback would be great in terms of the scope of the "Tabframe" API (if anything is missing or unnecessary). We can get into the details of naming, method arguments, hook points (e.g., window.navigator.tabframe.*), etc. later.