gmail problem investigated: frame onload

Koos Vriezen koos.vriezen at xs4all.nl
Mon Oct 4 20:13:03 BST 2004


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





More information about the kfm-devel mailing list