On Wed, Sep 26, 2012 at 4:51 PM, Brady Eidson <[email protected]> wrote:
> > 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. > > I mean all the port-specific boilerplate in http://trac.webkit.org/changeset/117613 as well. I don't have time to do this myself right now, but I'm happy to point folks in the right direction. 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
