[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: patch + examples, change frameset.rows from js
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-12-20 23:52:01
[Download RAW message or body]

On Friday 21 December 2001 00:35, koos.vriezen@xs4all.nl wrote:
> On Fri, 21 Dec 2001, David Faure wrote:
> 
> > On Thursday 20 December 2001 23:59, koos.vriezen@xs4all.nl wrote:
> > > So updateRendering is called on an inner document (as the heap goes up).
> > > Both documents return NULL as parentNode() and I couldn't find a way to
> > > get to this outer(=frameset) document.
> >
> > You can do that using the KHTMLPart's parentPart(), and then asking for
> > the document of that part.
> >
> > BUT.... there's nothing that can tell us that it's the parent document
> > that got modified. A frame could also modify another frame!
> > I think the only option we have is to go to the most-toplevel khtmlpart
> > (the parent frameset here, but framesets can also be nested!),
> > and from there call updateRendering() on all child khtml parts,
> > recursively (i.e. all child frames and framesets). Just in case the JS script
> > changed anything in another frame/frameset.
> 
> Maybe there should be a static lists of all documents. Or there could be a
> static list of all changedNodes. The last option would be quite easy to
> implement, just add static before QList<NodeImpl> changedNodes; in
> ./xml/dom_docimpl.h. I think I will try that tomorrow.

Interesting - you made me realize that a script can indeed modify another
window (e.g. one that it opened itself), not only documents in the
frameset/frame hierarchy.
I don't see how you would deal with a static list of nodes, since the
goal is to call updateRendering() on each document. What about
a static list of "changedDocuments" instead, and keeping the changed
nodes inside the document ? When doing doc->changedNodes.append(this)
we would also do s_changedDocs->append(doc) if doc isn't already
in s_changedDocs. Then after a script's execution we can call
updateRendering on each changed doc.

> > Frames (and the fact that they all have their HTML document)
> > are giving me quite some headaches at the moment too
> > (#36296, but it's not about the same thing).
> 
> I'm going out for a beer now. Maybe I good idea for jou?

Just solved that bug - without beer ;)

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://www.kde.org/people/david.html (my real webpage is down)
KDE 3.0: Konquering the Desktops
[prev in list] [next in list] [prev in thread] [next in thread]