On Wed, Apr 15, 2009 at 2:21 PM, Maciej Stachowiak <[email protected]> wrote: >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.
Pardon my thread necromancy, but is this SPI still used by Safari? A brief read through the code turns up tons of bugs related to this feature. Are these bugs important to fix? Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
