Bug 96998 - [GTK] run-webkit-tests unable to find TestExpectations for WK2
Summary: [GTK] run-webkit-tests unable to find TestExpectations for WK2
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Sergio Villar Senin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-18 04:08 PDT by Sergio Villar Senin
Modified: 2012-09-18 11:07 PDT (History)
7 users (show)

See Also:

Attachments
Patch (1.61 KB, patch)
2012-09-18 04:12 PDT, Sergio Villar Senin 		no flags Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sergio Villar Senin 2012-09-18 04:08:44 PDT 
[GTK] run-webkit-tests unable to find TestExpectations for WK2
Comment 1 Sergio Villar Senin 2012-09-18 04:12:15 PDT 
Created attachment 164530 [details]
Patch
Comment 2 Sergio Villar Senin 2012-09-18 04:32:39 PDT 
Comment on attachment 164530 [details]
Patch

Clearing flags on attachment: 164530

Committed r128874: <http://trac.webkit.org/changeset/128874>
Comment 3 Sergio Villar Senin 2012-09-18 04:32:43 PDT 
All reviewed patches have been landed.  Closing bug.
Comment 4 Dirk Pranke 2012-09-18 10:09:29 PDT 
Comment on attachment 164530 [details]
Patch

We should probably just make this the default implementation in base.py; it looks like no one is using that implementation anymore, and this clones the implementation in apple.py. Qt, Chromium, and Efl all use different logic.
Comment 5 Sergio Villar Senin 2012-09-18 11:07:01 PDT 
(In reply to comment #4)
> (From update of attachment 164530 [details])
> We should probably just make this the default implementation in base.py; it looks like no one is using that implementation anymore, and this clones the implementation in apple.py. Qt, Chromium, and Efl all use different logic.

Good point Dirk, I didn't review the other ports implementation when dealing with this issue. I can open a new bug moving the port specific implementations to the base class.