Brady Eidson writes:
> On Sep 26, 2012, at 2:46 PM, Tony Chang wrote:
>> I suppose we're biased in Mac-land where the mechanism originated,
>> but the "API" is simply a single string based API that only had to
>> be implemented once.
>>
>> Your comment leads me to understand that at least one ot
On Wed, Sep 26, 2012 at 4:51 PM, Brady Eidson wrote:
>
> On Sep 26, 2012, at 4:43 PM, Adam Barth wrote:
>
> Maybe a better solution is auto-generate all this boilerplate code? If we
> had a Settings.in file, we could generate all the port-specific code (and
> maybe even much of Settings.h/cpp)
On Sep 26, 2012, at 4:43 PM, Adam Barth wrote:
> Maybe a better solution is auto-generate all this boilerplate code? If we
> had a Settings.in file, we could generate all the port-specific code (and
> maybe even much of Settings.h/cpp) automatically. Then all of these patches
> would be one
Maybe a better solution is auto-generate all this boilerplate code? If we
had a Settings.in file, we could generate all the port-specific code (and
maybe even much of Settings.h/cpp) automatically. Then all of these
patches would be one-liners and work correctly on every port.
Adam
On Wed, Sep
On Sep 26, 2012, at 4:15 PM, Simon Fraser wrote:
> On Sep 26, 2012, at 4:13 PM, Brady Eidson wrote:
>
>> This works for any preference; Even a new one that has never been twiddled
>> in a regression test before.
>>
>> For example in http://trac.webkit.org/changeset/127956 we added a new tes
On Sep 26, 2012, at 2:49 PM, Adam Barth wrote:
>
>
> On Wed, Sep 26, 2012 at 2:35 PM, Brady Eidson wrote:
>
> On Sep 26, 2012, at 2:05 PM, Adam Barth wrote:
>
>> [re-sent from the proper address]
>>
>> On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth wrote:
>>
>>
>> On Wed, Sep 26, 2012 at
On Sep 26, 2012, at 4:13 PM, Brady Eidson wrote:
>
> On Sep 26, 2012, at 2:46 PM, Tony Chang wrote:
>
>> On Wed, Sep 26, 2012 at 2:35 PM, Brady Eidson wrote:
>> On Sep 26, 2012, at 2:05 PM, Adam Barth wrote:
>>> [re-sent from the proper address]
>>>
>>> On Wed, Sep 26, 2012 at 2:00 PM, Adam
On Sep 26, 2012, at 2:46 PM, Tony Chang wrote:
> On Wed, Sep 26, 2012 at 2:35 PM, Brady Eidson wrote:
> On Sep 26, 2012, at 2:05 PM, Adam Barth wrote:
>> [re-sent from the proper address]
>>
>> On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth wrote:
>> On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidso
On Wed, Sep 26, 2012 at 2:35 PM, Brady Eidson wrote:
>
> On Sep 26, 2012, at 2:05 PM, Adam Barth wrote:
>
> [re-sent from the proper address]
>
> On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth wrote:
>
>>
>>
>> On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson wrote:
>>
>>>
>>> On Sep 26, 2012, at 1:
On Wed, Sep 26, 2012 at 2:35 PM, Brady Eidson wrote:
> On Sep 26, 2012, at 2:05 PM, Adam Barth wrote:
>
> [re-sent from the proper address]
>
> On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth wrote:
>
>> On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson wrote:
>>
>>> On Sep 26, 2012, at 1:48 PM, Ryosu
On Sep 26, 2012, at 2:14 PM, Eric Seidel 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/w
On a related note, there is a gradual movement to pass more command
line flags along with each test to DRT during run-webkit-tests (to
toggle between pixel tests and non, change timeout values, etc.), and
being able to ensure we reset the state to the default between each
test is kinda necessary fo
On Sep 26, 2012, at 2:05 PM, Adam Barth wrote:
> [re-sent from the proper address]
>
> On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth wrote:
>
>
> On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson wrote:
>
> On Sep 26, 2012, at 1:48 PM, Ryosuke Niwa wrote:
>
>> On Wed, Sep 26, 2012 at 1:44 PM,
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
[re-sent from the proper address]
On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth wrote:
>
>
> On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson wrote:
>
>>
>> On Sep 26, 2012, at 1:48 PM, Ryosuke Niwa wrote:
>>
>> On Wed, Sep 26, 2012 at 1:44 PM, Simon Fraser wrote:
>>
>>>
>>> First, direct calls on
When overridePreferences was added back in the day:
http://trac.webkit.org/changeset/39212
The contract was that DRT would call resetDefaults between tests. I
don't know what the current status of resetToDefaults implementations
in other ports or in non-WK1 architectures.
On Wed, Sep 26, 2012 at
On Sep 26, 2012, at 1:44 PM, Simon Fraser wrote:
> * we should choose between internals.settings or
> testRunner.overridePreference if that makes sense.
I've recently been working on a new API and I've discovered that
internals.settings and testRunner.overridePreference go through different
l
On Sep 26, 2012, at 1:48 PM, Ryosuke Niwa wrote:
> On Wed, Sep 26, 2012 at 1:44 PM, Simon Fraser 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 pre
On Wed, Sep 26, 2012 at 1:44 PM, Simon Fraser wrote:
> We have a lot of tests that poke internal settings, via testRunner:
>
> testRunner.setFrameFlatteningEnabled(true);
>
> or window.internals:
>
> internals.settings.setPageScaleFactor(0.5, 0, 0);
>
> and some that poke preferences, like
We have a lot of tests that poke internal settings, via testRunner:
testRunner.setFrameFlatteningEnabled(true);
or window.internals:
internals.settings.setPageScaleFactor(0.5, 0, 0);
and some that poke preferences, like:
testRunner.overridePreference("WebKitUsesPageCachePreferenceK
20 matches
Mail list logo
