Frames

HTML5 Spec:

• 4.8.4 The iframe element
• 11.5 Frames and framesets
• 12.3.3 Frames

This is just a quick draft of a proposal for changing how frames are handled in NetSurf. Updates, changes, comments, etc are welcome.

Contents 1 Current frames implementation 1.1 Problems 2 New frames implementation 2.1 Evaluation 2.1.1 Advantages 2.1.2 Disadvantages 2.2 Changes required 3 Scrollbars 4 Other considerations

Current frames implementation

See the frames documentation.

Problems

• Complication of front end / core interface
• Only RO implementation works
• Not possible on some platforms
• Front ends poke around inside several browser_windows per window (or tab)
• Can be several gui_windows per window (or tab)

New frames implementation

In the following, "canvas" refers to the front end's "surface" onto which it plots whatever the core tells it to. There would only be one per window (or tab).

The front end only creates one gui_window per window (or tab). It never needs to know about browser_window objects, which will be internal to the core. The front end tells the core the size of the viewport. The front end never knows whether the viewport contains a simple page or a frameset, it just passes mouse actions in and plots into the canvas as the core instructs it.

For iframes, the core just renders the HTML content in the area of the page that the iframe occupies during HTML redraw. If scrollbars are present they are handled by the core scrollbar widget, and html_redraw calls for them to be redrawn. Clicks and mouse movement over iframes are passed on through to the content in question. IIRC we "drill down" into iframes already, so apart form getting the scroll offsets this may already be implemented.

For framesets, the canvas area we render into does not exceed the size of the viewable area in the window. So canvas size is equal to viewport size, and the front end's surface would be unscrollable. This means for large fixed-size frames in a small window, part of the frameset would get cropped. html_redraw would be updated to handle framesets. The canvas would be split up into rectangles with different contents in each rectangular area, according to the frameset. If the frame is scrollable and has scrollbars, scrollbars will be rendered for it. The core mouse tracking and clicking handling would be updated to handle framesets. It also needs to handle actions on the framesets themselves, e.g. frame resizing.

For regular pages (and possibly root framesets containing one frame and no nested framesets), the rendered canvas size is defined by layout in the normal way. So canvas size may exceed front end viewport size, making the front end's surface scrollable.

Evaluation

Advantages

• Much easier to develop a NetSurf front end
• Simplify existing front ends
• Fixes frames in all front ends without any work from front end maintainers
• All frames stuff in the core, so if somone fixes or improves it, it's improved on all platforms
• Fixes thumbnailing

Disadvantages

• Don't get native scrollbars or surfaces for individual frames

Mitigation - core scrollbar widget could optionally be overridden by front ends for native looking scrollbars

Changes required

• html_redraw() changed to handle frameset & iframe internally
• Mouse tracking and click handling updated to handle framesets
• Need to pass scrollwheel events to the core. If whatever the core has under the pointer can't be scrolled (further in that direction), the core tells the front end that it couldn't scroll anything and the front end can scroll the main viewport.

Thumbnailing should "just work".

Scrollbars

Possibility of front ends overriding core scrollbar widgets, for native look.

• Need to tell core the scollbar widths for layout
• Override scrollbar redraw
• Handle scrollbar clicks and core-generated scrollable area movements

Other considerations

• Frames history - Whole different kettle of ball games.