On Mon, Apr 9, 2012 at 3:24 PM, Maciej Stachowiak <mjs@apple.com> wrote:
On Apr 9, 2012, at 12:27 PM, Adam Barth wrote:
On Wed, Apr 15, 2009 at 2:21 PM, Maciej Stachowiak <mjs@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.
Ok. I'll file the ones I noticed. Thanks! Adam