summaryrefslogtreecommitdiff
path: root/frames.mdwn
blob: c1b1bc22cb0a1da4312272d68befca4400ebb11e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
[[!meta title="Frames"]]
[[!meta author="James Bursa"]]
[[!meta date="2011-11-26T22:20:19Z"]]


[[!toc]] HTML5 Spec:

-   [4.8.4 The iframe
    element](http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element)
-   [11.5 Frames and
    framesets](http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#frames-and-framesets)
-   [12.3.3
    Frames](http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#frames)

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

Current frames implementation
-----------------------------

See the [[frames documentation|documentation/frames]].

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