On Sep 26, 2012, at 4:43 PM, Adam Barth <[email protected]> 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-liners and work correctly on every port.
I would be all for that. I'm fuzzy on how the WebCore::Settings boiler plate would correctly apply to all WebKit ports in general, but I can see how it would easily solve our use case. ~Brady > > Adam > > > On Wed, Sep 26, 2012 at 4:28 PM, Brady Eidson <[email protected]> wrote: > > On Sep 26, 2012, at 4:15 PM, Simon Fraser <[email protected]> wrote: > >> On Sep 26, 2012, at 4:13 PM, Brady Eidson <[email protected]> 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 test >>> that twiddled the "WebKitStorageBlockingPolicy" preference and we didn't >>> need to change any DRT Mac code to accomplish this. >>> >>> Compared to adding a single implementation to internal.settings, this was >>> *NO* additional work. >> >> But is there code to undo this pref change for subsequent tests? > > I looked into the mechanism that does this. > > On Sep 26, 2012, at 1:44 PM, Simon Fraser <[email protected]> wrote: > >> I looked at testRunner.overridePreference(), and it doesn't appear to reset >> the value at the end of the test. > > That happens elsewhere, in: > static void resetDefaultsToConsistentValues() > > Indeed, each individual pref is currently managed with unique API calls here, > and the example I provided of WebKitStorageBlockingPolicy leaks. > > However, the key/value based preference mechanism can easily be augmented > within DRT in a general way that will fix this and all future key/value > preference usage. That change would only have to happen once per port > (assuming the port supports key/value based prefs) > > Brady > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo/webkit-dev > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
