Sorry for the naff Outlook format, I'm feeling lazy...
[mailto:email@example.com] On Behalf Of James Bursa
Sent: 09 August 2006 22:20
Subject: Re: Framesets, Frames and IFrames
> As most of you know, I've been updating the relevant chunks of
> NetSurf to allow for a more pleasing frame implemtation using the
> native window manager. The basics are complete, but there are still
> quite a few issues and suchlike that need to be resolved
before it gets anywhere near SVN.
Thanks for the overview. I now think this looks great and
will be much better than the current hack.
> How we now handle <frameset>, <frame> and
> The diagram below shows the basic manner in which we
extract and then
> later create the frame when the window is opened, ie when we have a
> browser_window to attach the information to.
So the box tree is still created, but contains nothing of
interest and is ignored when a frameset is present?
Yes, this is correct. When you traverse to a new _top page it deletes all
child browser_windows (ie frames and iframes) and you can briefly see the
non-frames content. This may be important at a later date for <object
> It's quite obvious that iframes need more work, and by more
> mean actually properly looking at. The main thing I really
> is the fact they get loaded twice (once into the parent
tree and once
> as a child
> window.) I'm not entirely sure how to achieve this, so some
> on this area would really be very helpful.
Are you still calling html_fetch_object? I think that you
will need to do this by calling fetchcache directly instead,
with a custom callback.
I was, but it all went a bit crashy then when you destroyed the content
from the browser window. I've now basically removed the iframe support until
it's done properly. I think there is some bug in content free-ing somewhere
(I've had it with a vanilla build) but I've not found it yet.
> Frame resizing isn't implemented at all. I got as far as
> ptr_lr icon before realising that the w3c spec says pretty much
> nothing about how it should work. Given a grid of things
> relative, percentage and pixel values, how do you modify
the dimensions of the pair?
I think that the way to do this is to alter computed pixel
sizes instead of the original values.
I've been working on frame resizing today and playing around with the real
values seems to work well for tests. I've just got a few issues to resolve
and then I'll make a test build/source available. I'm think things aren't
going to change too drastically now so I may check stuff into a branch for
everyone to play with.
> Frame margins are read correctly and stored to the
> which then fetches the content. I was thinking that we
could create a
> stylesheet from these and pass this with go_post so you're
flow is basically:
> 1) Create browser window from frameset
> 2) Create stylesheet for margins (and possibly other CSS
> 3) Call _go_post with the stylesheet
> 4) Stylesheet is merged with our default stylesheet and
then with the
> page stylesheet etc
This seems too complicated. I would change content_convert(),
content_reformat(), html_convert(), html_reformat(), and
layout_document() to take margins as well as width, height
(maybe as a struct).
Or pass _convert() and _reformat() width, height excluding
margin, and then render the frame contents offset by the
margin. That way it would work for images stand-alone in frames too.
Sounds good. I was thinking along the lines that this would allow us to
support user stylesheets for 'free' in the process which has been a feature
request that I agree with.
> Things that have got worse
> The obvious thing here is history.
It's no worse; it doesn't do proper frame history now either.
We don't have a thumbnail at the moment. One upshot is that each individual
frame has history, so you can use Navigate->Back and friends (or even bring
up a local history window) for each frame.
> We need to recursively store the entire frameset details and
> recreate this accordingly. I've vaguely begun this by
moving all the
> page data associated with a history_entry into a separate 'struct
> page' which can then be updated accordingly.
We'll end up with the same structure as for framesets. Can we
just reuse the same data structure?
That's my basic intention. Not done any real code here though, so there may
be something I haven't seen yet :-s
When a frameset page is visited, the frameset data structures
could be recursively copied into the history. I'm not sure
how to implement going back to a history entry. We could
synthesize a CONTENT_HTML and copy (or
point) the frameset structures into it from the history. In
fact, maybe we should do this for following a link too,
instead of modifying the content.
Browser windows could be modified to contain either a
content, or a frameset. Does this make any sense? I have only
looked at the code very briefly.
Synthesizing a CONTENT_HTML sounds good, but for nested framesets this
isn't so easy unfortunately. I definitely think building up the
browser_window tree and then just calling _go would be the simplest and
least-hacky method (we can just pass the struct from history and the code
will 'just work' in theory.)
> There's a copy of a recent-ish version of my new code on
> server, so feel free to take a peek.
Can someone remind me of the URL please?
I'd wait until the next one I check in though as I've trimmed quite a few
things and finished off many others.