Bug 85689 – layoutTestController.overridePreference doesn't work so well in a parallel world

• Status: NEW
• Component: Tools / Tests

[Dean Jackson]

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.

[Simon Fraser (smfr)]

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?

[Dean Jackson]

It surprises me as well - but I certainly see my setting if I run

defaults read DumpRenderTree

[Simon Fraser (smfr)]

Maybe this is not an issue normally because DRT sets prefs to default values before every test.

[Tim Horton]

(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?

[Zan Dobersek]

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?

[Zan Dobersek]

(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.