Bug 80567 - LayoutTestHelper could get torn down earlier (mostly to reset color profile)
Summary: LayoutTestHelper could get torn down earlier (mostly to reset color profile)
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Dirk Pranke
URL:
Keywords:
: 81731 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-07 21:20 PST by Tim Horton
Modified: 2012-03-23 14:10 PDT (History)
7 users (show)

See Also:


Attachments
Patch (5.40 KB, patch)
2012-03-21 13:58 PDT, Dirk Pranke
rniwa: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Horton 2012-03-07 21:20:59 PST
LayoutTestHelper currently gets torn down when run-webkit-tests finally quits. However, if you have run-webkit-tests launch a browser to the results and wait on that instance, it could be a while before it's torn down.

Since LayoutTestHelper is designed mostly to deal with setting up things required for generating consistent results, etc. (i.e. changing the display color space), it seems like it only needs to be alive while the tests are running.

It would be nice if it were killed as soon as the last test was finished, before the browser with results is launched, so that the user's display can go back to its normal color space as soon as possible.
Comment 1 Tim Horton 2012-03-20 20:23:43 PDT
*** Bug 81731 has been marked as a duplicate of this bug. ***
Comment 2 Dirk Pranke 2012-03-21 13:07:40 PDT
makes sense.
Comment 3 Dirk Pranke 2012-03-21 13:08:20 PDT
On a mildly related note, I'm not actually sure why we wait for the browser to exit on the mac port. The chromium port doesn't; is this desired behavior?
Comment 4 Tim Horton 2012-03-21 13:18:10 PDT
(In reply to comment #3)
> On a mildly related note, I'm not actually sure why we wait for the browser to exit on the mac port. The chromium port doesn't; is this desired behavior?

Not at all; I assumed it happened on Chromium too!
Comment 5 Dirk Pranke 2012-03-21 13:58:26 PDT
Created attachment 133109 [details]
Patch
Comment 6 Dirk Pranke 2012-03-21 17:20:13 PDT
Filed bug 81845 and uploaded a patch to not block on safari at the end ...
Comment 7 Dirk Pranke 2012-03-23 14:10:06 PDT
Committed r111902: <http://trac.webkit.org/changeset/111902>