Bug 37793

Summary: [Chromium] new-run-webkit-tests should use WebKitDriver for --use-drt
Product: WebKit Reporter: Kent Tamura <tkent>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, dpranke, eric, tony
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Other   
OS: OS X 10.5   
Bug Depends on: 37645    
Bug Blocks: 35902    
Attachments:
Description Flags
Patch none

Kent Tamura
Reported 2010-04-19 01:23:37 PDT
[Chromium] new-run-webkit-tests should use WebKitDriver for --use-drt
Attachments
Patch (2.02 KB, patch)
2010-04-19 01:26 PDT, Kent Tamura 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Kent Tamura
Comment 1 2010-04-19 01:26:39 PDT
Created attachment 53659 [details] Patch
Eric Seidel (no email)
Comment 2 2010-04-19 01:29:16 PDT
Comment on attachment 53659 [details] Patch User.open_url is probably better than calling webbrowser directly: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/system/user.py#L81 it allows us to more easily mock out this code for testing. This is a rather strange class inversion. I guess eventually Chromium will be a subclass of WebKitPort.
Eric Seidel (no email)
Comment 3 2010-04-19 01:29:44 PDT
Seems maybe we should have called them TestShellDriver and DumpRenderTreeDriver.
Eric Seidel (no email)
Comment 4 2010-04-19 01:31:02 PDT
Comment on attachment 53659 [details] Patch I guess ChromiumPort may not have access to a tool object, which would expose the User() object, so this is probably the best we have for now.
Kent Tamura
Comment 5 2010-04-19 01:41:03 PDT
Comment on attachment 53659 [details] Patch Clearing flags on attachment: 53659 Committed r57806: <http://trac.webkit.org/changeset/57806>
Kent Tamura
Comment 6 2010-04-19 01:41:13 PDT
All reviewed patches have been landed. Closing bug.
Dirk Pranke
Comment 7 2010-04-19 10:36:40 PDT
(In reply to comment #2) > (From update of attachment 53659 [details]) > User.open_url is probably better than calling webbrowser directly: > http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/system/user.py#L81 > it allows us to more easily mock out this code for testing. > > This is a rather strange class inversion. I guess eventually Chromium will be > a subclass of WebKitPort. If this were to become the case, then WebKitPort should probably be merged into port/base.py. It is useful to think of base.py as declaring an interface, but it really is a base class. The only other implementations that wouldn't inherit from WebKitPort would be the testing/mock classes, and they can override whatever they need do.
Eric Seidel (no email)
Comment 8 2010-04-19 12:14:10 PDT
I agree that I think eventually we'll push more code down into base instead of WebKitPort or ChromiumPort.
Note You need to log in before you can comment on or make changes to this bug.