[webkit-dev] Is it OK to remove Frame::setIsDisconnected() and isDisconnected() ?
mjs at apple.com
Wed Apr 15 14:21:16 PDT 2009
On Apr 15, 2009, at 1:29 PM, Sverrir Á. Berg wrote:
> Hi Adam,
> Thanks for the links. These are simply exposing the functions as a
> formal a API's. I understand that you typically don't want to
> change externally exposed API's but these can easily be stubbed out
> (or removed).
> I should have pointed out in my original email that I have tried to
> remove these API's and I can still run all the WebKit/Mac tests
> fine. So at least two things are missing (IMHO) - tests that verify
> that this functionality is working as intended and documentation to
> tell what that intent is. But this is only required if somebody is
> actually using these functions...
The API (system-private API actually, or "SPI" as we call it) in
question is used by Safari. I don't believe it would be safe to remove
this flag. The intent of the WebFrame API is that you can make a frame
act (from the point of view of content inside it) as if it is a top-
level frame, even though it is actually a subframe. One case where
this might be useful is if you wanted to build a custom browser-like
UI partially using HTML, which could then load pages as subframes
without exposing that fact. It is true and unfortunate that we don't
have tests - the ObjC API does not have as much test coverage as
features exposed to Web content.
> On Wed, Apr 15, 2009 at 4:17 PM, Adam Roben <aroben at apple.com> wrote:
> On Apr 15, 2009, at 3:48 PM, Sverrir Á. Berg wrote:
> Working on a change in FrameTree and noticed that the checks in
> top() and parent() for 'checkForDisconnectedFrame' rely on a flag in
> Frame that as far as I can tell is never set.
> So my naive question is: Can I remove the corresponding code from
> Frame and FrameTree? If not I would like if somebody could explain
> how they are used so I don't break anything with my change.
> More detail:
> * My search for calls to Frame::setIsDisconnected reveals no callers
> in WebKit, Chromium or Google code search.
> There are two callers:
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev