What if a html page uses a iframe for images?

Sun Aug 1 01:17:42 BST 2004

On Sat, Jul 31, 2004 at 02:29:19AM +0200, Koos Vriezen wrote:
> On Wed, Jul 28, 2004 at 08:50:11PM +0200, Koos Vriezen wrote:
> > Was playing with this on current:
> > <html><head><script>
> >             var frame;
> >             function changeToImage (lnk) {
> >                 frame=frames[0];
> >                 frame.location = "image.jpg";
> >                 func = changeToImage2;
> >                 alert ("done1");
> >             }
> >             function changeToImage2 (lnk) {
> >                 frame.location = "simple.html";
> >                 func = changeToImage;
> >                 alert ("done2");
> >             }
> >             var func = changeToImage;
> >     </script></head>
> >     <body>
> >         <div onClick="javascript:func (this)">click me</div>
> >         <iframe src="simple.html"</iframe>
> >     </body>
> > </html>
> 
> Ok, attached something that makes the above work. Note, the patch is far
> from finished, just enough for this example.
> This idea is to store a KParts::ReadOnlyPart pointer and a DOM::Node of
> the frame in its parent document in KJS::Window instead of only the
> KHTMLPart pointer of the frame's document.
> If the frame's part is destroyed and DOM::Node handle is not zero (I'm
> not quite sure that if node is detached, this handle becomes zero *), a
> possible new KPart is search in this handle's document. If one
> is found and it's not a KHTMLPart, still some functionality can be uses.
> Such as changing the url (emit openURLRequest on its browser extension)
> 
> What needs to be done is make sure that *) is correct assumption (and do
> I need getDomNode()?) and also allow document.frames[0] to work for frames
> that are transformed to other KParts (in the above case it works because
> of the 'frame' variable). Also some other properties, like frame dimension,
> could work for other KParts.

Well this proof of concept with the hardest issue implemented,
not unlike other times, turns out that the todo's are impossible this way.
Problem is that a new KHTMLPart in a frame is unaware of an existing
one. So the KJS::Window, or jscript object, should be stored somewhere
outside the KHTMLPart.
Attached a new version that stores it in khtml::ChildFrame, as that one
also remains when swapping parts. Because of keeping track of livetime
of this one, I made it to a QObject. Unfortunately, as the copy ctor of
QObject is private, I had to change the m_frames and m_objects to a
pointer list.
What works is the above example. Now also if a second 'click me' does it
with window.frames['some name'] evaluates to the same KJS::Window, even
if its a KHTMLImage. What doesn't is window.frames[num] when its a
KHTMLImage, because KHTMLPart::frames() does not return non KHTMLPart
elements (needs a variant that does).
So now I can look for the traffic jams :-)

> > > Koos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kjs_window.patch3.bz2
Type: application/octet-stream
Size: 14098 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040801/ea0a837f/attachment.obj>