Sometimes setting a preference causes a default to be written for the DumpRenderTree process (e.g. on OSX). Unfortunately if you're explicitly testing for disabling a feature by a preference override, this can go crazy when there are multiple tests running at the same time. The tests that are expected to run while the feature is enabled may fail because the other test has temporarily turned it off. Also, this state seems to confuse the automatic reset of preferences.
I'm surprised that setting a pref in DRT interferes with other DRT instances; it should never get written to disk. How does that not break with other prefs?
It surprises me as well - but I certainly see my setting if I run defaults read DumpRenderTree
Maybe this is not an issue normally because DRT sets prefs to default values before every test.
(In reply to comment #3) > Maybe this is not an issue normally because DRT sets prefs to default values before every test. Even so, if the DRT instances are sharing preferences, isn't it still possible for a different one to set it between resetWebViewToConsistentStateBeforeTesting() and the test running?
From the test's point of view, setting the preference to preferred value could be done through the window.internals object. Is that an acceptable workaround?
(In reply to comment #5) > From the test's point of view, setting the preference to preferred value could be done through the window.internals object. Is that an acceptable workaround? To clarify, the test in mind here is fast/animation/request-animation-frame-disabled.html.