[GTK] Add WestonDriver, use it when appropriate
Created attachment 207479 [details] Patch
Comment on attachment 207479 [details] Patch Still needs a unit test. Reviews welcome, though.
Comment on attachment 207479 [details] Patch Attachment 207479 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/1241366 New failing tests: http/tests/security/cross-origin-plugin-private-browsing-toggled.html
Created attachment 207565 [details] Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-15 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.3
Comment on attachment 207479 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=207479&action=review Looks good to me! > Tools/Scripts/webkitpy/port/westondriver.py:64 > + # Give Weston a bit of time to set itself up. > + time.sleep(self._startup_delay_secs) I wonder if you could just listen to the socket and continue when it's alive?
Comment on attachment 207479 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=207479&action=review >> Tools/Scripts/webkitpy/port/westondriver.py:64 >> + time.sleep(self._startup_delay_secs) > > I wonder if you could just listen to the socket and continue when it's alive? I understand how sleeping at the start is not really an ideal solution to the problem, but I think listening to sockets here would, on the other hand, be a complex and not-that-testable solution. I don't believe there's anything wrapping sockets (and making them testable) in webkitpy at the moment. So at least for now I'd propose keeping the time.sleep call, possibly address it later while coming up with a unit test for the driver.
(In reply to comment #6) > (From update of attachment 207479 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=207479&action=review > > >> Tools/Scripts/webkitpy/port/westondriver.py:64 > >> + time.sleep(self._startup_delay_secs) > > > > I wonder if you could just listen to the socket and continue when it's alive? > > I understand how sleeping at the start is not really an ideal solution to the problem, but I think listening to sockets here would, on the other hand, be a complex and not-that-testable solution. I don't believe there's anything wrapping sockets (and making them testable) in webkitpy at the moment. > > So at least for now I'd propose keeping the time.sleep call, possibly address it later while coming up with a unit test for the driver. Sounds like a reasonable solution for now. If this is causing trouble, we can always re-approach it and use something more foolproof. I know that in the past we've had issues waiting for Xvfb to start.
Comment on attachment 207479 [details] Patch Clearing flags on attachment: 207479 Committed r153439: <http://trac.webkit.org/changeset/153439>
All reviewed patches have been landed. Closing bug.