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

List:       kfm-devel
Subject:    Re: gmail problem investigated: frame onload
From:       Luke Randall <luke.randall () gmail ! com>
Date:       2004-10-04 19:08:14
Message-ID: 2c8465c2041004120872b4bb86 () mail ! gmail ! com
[Download RAW message or body]

Hi

If anyone wants to test Gmail I unfortunately don't have any invites
at the moment, but I have a spare account, so get in touch with me and
I will gladly give you the username and password to test it out on...

-Luke


On Mon, 4 Oct 2004 19:46:16 +0200, David Faure <faure@kde.org> 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?
> 
> 
> 
> --
> David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
> Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
> 


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