|Summary:||layoutTestController.overridePreference doesn't work so well in a parallel world|
|Product:||WebKit||Reporter:||Dean Jackson <dino>|
|Component:||Tools / Tests||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||ap, dpranke, simon.fraser, thorton, zan|
|Version:||528+ (Nightly build)|
Description Dean Jackson 2012-05-04 19:14:49 PDT
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.
Comment 1 Simon Fraser (smfr) 2012-05-04 23:22:57 PDT
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?
Comment 2 Dean Jackson 2012-05-05 14:07:44 PDT
It surprises me as well - but I certainly see my setting if I run defaults read DumpRenderTree
Comment 3 Simon Fraser (smfr) 2012-05-06 21:42:28 PDT
Maybe this is not an issue normally because DRT sets prefs to default values before every test.
Comment 4 Tim Horton 2012-05-06 21:46:11 PDT
(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?
Comment 5 Zan Dobersek 2012-07-24 07:51:18 PDT
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?
Comment 6 Zan Dobersek 2012-07-24 07:57:07 PDT
(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.