[webkit-dev] Is it OK to remove Frame::setIsDisconnected() and isDisconnected() ?

[Adam Barth]

On Mon, Apr 9, 2012 at 3:24 PM, Maciej Stachowiak <mjs at 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 at 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