On Sep 26, 2012, at 2:14 PM, Eric Seidel <e...@webkit.org> wrote:

> TestExpectation files on all ports are full of:
> # unskip these tests when we add obscure-drt-feature-x
> 
> http://trac.webkit.org/browser/trunk/LayoutTests/platform/wk2/Skipped#L107
> http://trac.webkit.org/browser/trunk/LayoutTests/platform/wk2/Skipped#L209
> http://trac.webkit.org/browser/trunk/LayoutTests/platform/wk2/Skipped#L247

I believe these will go away with a single implementation of 
overridePreference().

> http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/TestExpectations#L115
> http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/TestExpectations#L948
> http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/TestExpectations#L958

But am not so sure here.

> I would agree with Adam, and the more we can move to window.internals,
> the less technical debt we incur with each new DRT feature.

> 
> I would love to see overridePreferences go away (or only be used for
> preferences which need to test the WebKit-side plumbing).

DRT/WKTR are important not only in that they test WebCore but also in that they 
test the WebKit they embed.

This seems like a short sided conclusion based on convenience.

~Brady

> 
> as just a few examples. :)  I didn't even look at the less-well-funded ports. 
> :)
> 
> On Wed, Sep 26, 2012 at 4:05 PM, Adam Barth <aba...@webkit.org> wrote:
>> [re-sent from the proper address]
>> 
>> On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth <abarth@nowhere> wrote:
>>> 
>>> 
>>> 
>>> On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson <beid...@apple.com> wrote:
>>>> 
>>>> 
>>>> On Sep 26, 2012, at 1:48 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
>>>> 
>>>> On Wed, Sep 26, 2012 at 1:44 PM, Simon Fraser <simon.fra...@apple.com>
>>>> wrote:
>>>>> 
>>>>> 
>>>>> First, direct calls on testRunner that just set preferences should be
>>>>> migrated to internals.settings or testRunner.overridePreference calls, I
>>>>> think (I don't know if either is preferred).
>>>> 
>>>> 
>>>> I support the idea of unifying the approaches and just use
>>>> internals.settings. However, the last time I checked, Alexey had some
>>>> concerns about using internals due to settings may not be properly
>>>> propagated to WebKit2 layer. Has this concern been addressed?
>>>> 
>>>> 
>>>> In general I prefer the overridePreference() calls whenever they exist.
>>>> 
>>>> internals.settings are not exposed in any real-world product whereas
>>>> preferences exist in each platform's WebKit-layer API that they expose to
>>>> their embedders in some form.
>>> 
>>> 
>>> The main downside of overridePreference is that it requires that you
>>> expose an API for twiddling the preference on every port.  That can lead to
>>> us exposing unneeded APIs (making them harder to remove) and to a bunch of
>>> port-specific code in an otherwise port-independent patch.
>>> 
>>> IMHO, we should prefer InternalSettings unless we need to test the
>>> WebKit-layer code.
>>> 
>>> Adam
>>> 
>> 
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to