[Webkit-unassigned] [Bug 75707] Many css2.1 tests fail on Apple's Windows port under NRWT

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 6 14:07:21 PST 2012


https://bugs.webkit.org/show_bug.cgi?id=75707





--- Comment #8 from Dirk Pranke <dpranke at chromium.org>  2012-01-06 14:07:21 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> > Hm. This is a problematic feature in the face of parallelism.
> > 
> > How would this be supposed to work with multiple DRTs running at the same time? Does the persistent user style sheet affect any DRT running on the machine, or is it only in memory? I.e., how do I keep this from affecting DRTs running tests in other directories?
> 
> Right now I think it gets persisted out to disk with the rest of DRT's preferences, but I don't think that is a requirement. In fact, it's probably an accident that DRT's preferences get written to disk. So I don't think this presents a problem for concurrent testing, as long as we stop writing out preferences to disk.
> 
> > Could we maybe do something like that instead where every test would be told to do something different before/after/during the test but it was in-memory?
> 
> Perhaps. Presumably that would require DRT changes. I also wonder if it would slow things down, since we'd be loading 3 files (prologue + test + epilogue) for every css2.1 test.

The general model I have in mind is that the command lines would potentially change per directory, and so when DRT was handed a test in a new directory, it would get restarted with the change. 

So, for something like this we could add a --use-user-style=$foo flag (or some equivalent) for this directory, and any test run in that directory would get handed that flag. We could add a more general --prologue and --epilogue flags to run those files on startup and shutdown (and the epilogue might not even be needed if the scripts weren't changing persistent settings).

Obviously this would require some DRT changes, but it doesn't seem like they'd be too bad.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list