Shared chromium process / debugging client about cuprite HOT 5 CLOSED

I see a few issues here:

1. If one batch of parallel testing exits earlier than the rest I think it will trigger quit on the driver which in turn kill browser because it won't be aware of the rest batches. This will mess up the rest of the tests. If it won't kill the browser after ruby exits the browser would be left in memory which is not good too.

2. The protocol supports multi-client debugging for tabs but in order to manipulate the browser itself users have to connect to a dedicated url which is generated when browser starts, chrome spits it to stdout for example DevTools listening on ws://127.0.0.1:31337/devtools/browser/93806b13-fce0-43c0-bd46-23922bb7c592 with this url and protocol we can create pages and manipulate them. There are also websockets for each page. We can connect to http://127.0.0.1:31337/json but it only shows urls for pages for example ws://127.0.0.1:31337/devtools/page/FAB21C8A5AE08589AD81B13BCB7CB460 not the browser url.
   So even if host and port are static we still have to somehow start a few capybara sessions parse address from one of them save it somewhere (filesystem?) so the others could read it and connect to the same browser.

With all that +1s on start seems not that bad to me :)

from cuprite.

@ianks I'm gonna close it for now, feel free to share your thoughts with us if I'm wrong I might have missed something.

from cuprite.

@route Sorry for the delay, busy week. Thanks for taking the time to respond in detail 😄

I see a few issues here:

1. If one batch of parallel testing exits earlier than the rest I think it will trigger quit on the driver which in turn kill browser because it won't be aware of the rest batches. This will mess up the rest of the tests. If it won't kill the browser after ruby exits the browser would be left in memory which is not good too.

Yes you are right. However, in this case the leader node should be responsible for maintaining the browse state, rather than each individual test worker. I would require some decoupling of Browser <-> Process (https://github.com/machinio/cuprite/blob/master/lib/capybara/cuprite/browser.rb#L246) but I think it's doable.

2. The protocol supports multi-client debugging for tabs but in order to manipulate the browser itself users have to connect to a dedicated url which is generated when browser starts, chrome spits it to stdout for example DevTools listening on ws://127.0.0.1:31337/devtools/browser/93806b13-fce0-43c0-bd46-23922bb7c592 with this url and protocol we can create pages and manipulate them. There are also websockets for each page. We can connect to http://127.0.0.1:31337/json but it only shows urls for pages for example ws://127.0.0.1:31337/devtools/page/FAB21C8A5AE08589AD81B13BCB7CB460 not the browser url.
   So even if host and port are static we still have to somehow start a few capybara sessions parse address from one of them save it somewhere (filesystem?) so the others could read it and connect to the same browser.

Yes, good point. I think the leader<->worker architecture could solve this as well, since it could manage and provide the necessary connection details to the workers.

Thoughts?

from cuprite.

Sounds good with this architecture, do you want to take a stab?

from cuprite.

Check #92

from cuprite.