[webkit-dev] Settings and Preferences in layout tests
eric at webkit.org
Wed Sep 26 14:14:27 PDT 2012
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).
TestExpectation files on all ports are full of:
# unskip these tests when we add obscure-drt-feature-x
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 <abarth at webkit.org> wrote:
> [re-sent from the proper address]
> On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth <abarth at nowhere> wrote:
>> On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson <beidson at apple.com> wrote:
>>> On Sep 26, 2012, at 1:48 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>> On Wed, Sep 26, 2012 at 1:44 PM, Simon Fraser <simon.fraser at apple.com>
>>>> 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.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev