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

List:       kfm-devel
Subject:    Re: gmail problem investigated: frame onload
From:       Koos Vriezen <koos.vriezen () xs4all ! nl>
Date:       2004-10-04 19:13:03
Message-ID: 20041004191303.GA89728 () xs4all ! nl
[Download RAW message or body]

On Mon, Oct 04, 2004 at 07:46:16PM +0200, David Faure wrote:
> On Monday 04 October 2004 18:53, Allan Sandfeld Jensen wrote:
> > I've been looking at how Safari handles it, and have come up with the attached 
> > patch. It works on your test example, but I do not have a gmail-account to 
> > test with.
> 
> Ouch. Obviously if I choose one way to fix it, they chose another way and didn't \
> send us a patch... 
> But comparing the two, I really prefer my approach.
> Their patch is adding a hack to dispatchWindowEvent itself, and \
> DocumentImpl::ownerElement() looks awful since it has to navigate through 6 classes \
> [and might not work with Koos' ChildFrame changes]. I was missing something like \
> ownerElement() though, when looking for a way to fix the bug, but I think the \
> signal/slot solution is much cleaner. 
> What do other people think?

Not judging either of the patches, but the navigate through 6 classes
can be more simple now. See: kdelibs/khtml/khtmlpart_p.h -r1.54 -r1.55.
Well, it only saves one class though :-), but it's the most expensive
lookup 'ChildFrame *childFrame = parent->frame(childPart);'

+ElementImpl *DocumentImpl::ownerElement()
+{
+    KHTMLView *childView = view();
+    if (!childView)
+        return 0;
+    KHTMLPart *childPart = childView->part();
+    if (!childPart)
+        return 0;
+    KHTMLPart *parent = childPart->parentPart();
+    if (!parent)
+        return 0;
+    ChildFrame *childFrame = parent->frame(childPart);
+    if (!childFrame)
+        return 0;
+    RenderPart *renderPart = childFrame->m_frame;
+    if (!renderPart)
+        return 0;
+    return static_cast<ElementImpl *>(renderPart->element());
+}

Since the ChildFrame changes, the KHTMLPart already has the renderPart
of itself in d->m_frame. So, view()->part()->d->m_frame->m_frame->element()
should evaluate to the parent IFRAME element of a given child frame.
Note that d->m_frame->m_frame is 0L for top level documents.
(forgive me the name confusion between d->m_frame (a childframe, which
is new) and d->m_frame->m_frame (a renderpart, that already was there))

Koos


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