[13:46] <frankban> hazmat: IIRC, our websocket server in Juju does not support the old hixie76 protocol, right? I only see references to hybi07. PhantomJS still supports only the former protocol.
[13:49] <frankban> gary_poster, hazmat: here is my attempt to integrate selenium and phantom in order to run integration tests. http://pastebin.ubuntu.com/1506674/ It does not work (I think for the reason above). It works replacing phantom with a more conventional driver (i.e. firefox).
[13:50] <gary_poster> frankban, given the lbox approach we have right now, if we could get the tests working in selenium and FF/chrome that would be a huge step forward
[13:51] <gary_poster> we'd want it running locally, of course.
[13:54] <gary_poster> I think phantomjs would be fine for running the existing tests even without addressing the websocket issue
[14:00] <benji> another component for implementing browser tests: http://pypi.python.org/pypi/xvfbwrapper
[14:04] <frankban> gary_poster: I agree. Especially for the charm, it would be great to actually test that the services and/or websocket connections are there instead of just checking the status of web requests. benji: that's cool, so it allows to run tests without actually having an X server running
[14:05] <benji> frankban: it runs an X that only renders to memory
[14:06] <gary_poster> frankban, +1 on improved charm test, yeah
[14:12] <hazmat> frankban, that's unfortunate hixie76 is rather broken
[14:12] <hazmat> gary_poster, phantomjs running mocha tests directly is also a win, but i suspect is more work
[14:13] <frankban> hazmat: yes, they are working on it, AFAICT, they need to integrate a newer version of webkit in phantom
[14:16] <hazmat> frankban, its using qtwebkit..
[14:19] <frankban> hazmat: http://code.google.com/p/phantomjs/issues/detail?id=31
[14:19] <frankban> hazmat: yes, qtwebkit
[15:21] <bac> bcsaller: hi ben, will have you time to pair this afternoon on the pan/zoom issue?
[15:22] <bcsaller> bac: yeah, I should
[15:22] <bac> bcsaller: great
[15:28] <gary_poster> bac bcsaller benji frankban goodspud Makyo teknico call in 2
[15:29] <gary_poster> (hazmat is sick)
[15:29] <frankban> gary_poster, benji: it works: http://pastebin.ubuntu.com/1506878/
[15:29] <benji> frankban: very nice!
[16:24] <gary_poster> hey goodspud.  you available for juju-ui talk?
[16:24] <goodspud> Yep
[17:14] <benji> I have not done exhaustive testing, but I think our caching story still isn't right.  It appears that I have to clear the browser cache pretty much every time I make any change.
[17:25] <bac> hello bcsaller, you free?
[17:26] <bcsaller> bac: yes
[17:26] <bac> bcsaller: to the bat channel?
[17:26] <bcsaller> bac: there
[20:15] <benji> if anyone would like to review the dramatically changed login branch, please see https://codereview.appspot.com/7007047
[20:19] <gary_poster> I, personally, can barely contain my excitement
[20:21] <benji> About an hour ago I could barely contain other extream emotions.
[20:22] <gary_poster> :-)
[20:31] <gary_poster> benji, AFAICT the login implementation on the rapi/juju side does not return provider_type and default_series on success, the way it is supposed to according to step 5 of http://paste.ubuntu.com/1397723/
[20:32] <gary_poster> To your knowledge am I right?
[20:33] <gary_poster> yeah, pretty sure I am right
[20:33] <gary_poster> "{"log": [["info", "Login success"]], "request_id": 1, "user": "admin", "op": "login", "password": "admin", "result": true}"
[20:33] <benji> gary_poster: I don't know but I can check.  That paste went out the window after revision 1 that assumed the back-end actually worked the way it describes.
[20:33] <gary_poster> benji right :-/
[20:45] <gary_poster> benji, you available for 10 minute review call?
[20:45] <benji> gary_poster: sure
[20:46] <gary_poster> benji, cool.  juju-ui is available