On Apr 9, 2012, at 12:27 PM, Adam Barth wrote: > On Wed, Apr 15, 2009 at 2:21 PM, Maciej Stachowiak <m...@apple.com> 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?
Yes. It is used by the "Reader" feature of Safari. > A brief read through the code turns up tons of bugs related to this > feature. Are these bugs important to fix? Hard to say, without knowing what the specific bugs are. Regards, Maciej _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
