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(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