{"push_id":578224030,"size":4,"distinct_size":4,"ref":"refs/heads/jpevarnek-inprogress-copypaste","head":"853766f773b340f6ad335999f3ed65c572e4d5a2","before":"83880eb26e11184e5c10984a8e31f771a10e1407","commits":[{"sha":"a67bcb3568ffa998b7f1563a2006d66c69f84a60","author":{"email":"b6009317dda9c8147d39bb1612ef26837c1c6663@google.com","name":"Jonathan Pevarnek"},"message":"Update RemoteInstance to be backed by RemoteConnection\n\nThis change updates the RemoteInstance class to use RemoteConnection to\nback the instance instead of directly accessing socksToRtc and rtcToNet.\nThere was an incredible level of code duplication between the classes,\nso this makes a lot more sense in the long run.\n\nWhen a RemoteInstance is created, we set up a new RemoteConnection in\nthat will handle all the backend functionality (the RemoteInstance still\nhandles things such as checking for permissions since that's not needed\nfor all connections).  We register an update function to it that checks\nthe type of each update and does an appropriate action for that.  For\nmost of them, this just means proxying the callback to ui.update,\nswitching the type, and adding an instanceId to it.  For state, we cache\nthe values locally.  Other than that, it's a pretty straightforward\nconversion since most of the code in RemoteConnection is essentially a\ncopy-paste of the RemoteInstance code.\n\nTesting changes:\n\nThe fakeSocksToRtc object we use now actually records when handlers are\nbound to it and will fire the stopped handler when stop is called.  The\nRemoteConnection code relies on the callback actually being triggered so\nthat was causing test failures.\n\nFor the generic_ui tests, we now spy on UserInterface::showNotification\nsince the code to trigger one of the notifications was moved out of the\ncore module and into the appropriate function within the UI.  This was\ncausing tests to fail since PhantomJS apparently does not have the\nNotification class","distinct":true,"url":"https://api.github.com/repos/uProxy/uproxy/commits/a67bcb3568ffa998b7f1563a2006d66c69f84a60"},{"sha":"605757d52667c5e94a95e787a30208e79641b7f8","author":{"email":"b6009317dda9c8147d39bb1612ef26837c1c6663@google.com","name":"Jonathan Pevarnek"},"message":"Set up the structure for the connectors between core and ui\n\nThis sets up handlers in the core for dealing with the expected actions\nwe will eventually receive from the UI.","distinct":true,"url":"https://api.github.com/repos/uProxy/uproxy/commits/605757d52667c5e94a95e787a30208e79641b7f8"},{"sha":"2a13e23164230637846c839e6b3ac0f506b35e8e","author":{"email":"b6009317dda9c8147d39bb1612ef26837c1c6663@google.com","name":"Jonathan Pevarnek"},"message":"Add the UI component for the copy-paste app\n\nThis adds the actual front-end user-experience components for the\ncopy-paste workflow.  The structure for the poylmer element is very\nsimilar to the rest of the app: there is an element in the root view\nthat is hidden when the view mode is not in copy+paste mode.\n\nThe connection between the UI and the core is generally handled in the\nui script.  This takes care of displaying the messages as well as the\nactions for when the connection is terminated.\n\nFor message display, there were a couple different ways I attempted to\nstructure this, however, they did not work in the end.  The first way I\ntried was to delay showing messages until they were completely received,\nhowever, this had some abstraction concerns when checking for\ntermination conditions.  The second way was to handle batching of\nmessages on the remote side and send them to the UI all at once,\nhowever, this ran into a problem with some of the messages not making it\nthrough (due to the order of some of the callbacks).","distinct":true,"url":"https://api.github.com/repos/uProxy/uproxy/commits/2a13e23164230637846c839e6b3ac0f506b35e8e"},{"sha":"853766f773b340f6ad335999f3ed65c572e4d5a2","author":{"email":"b6009317dda9c8147d39bb1612ef26837c1c6663@google.com","name":"Jonathan Pevarnek"},"message":"Add a handler to send URL data to the copy+paste connection\n\nThis adds a handler to chrome that will block loads of\nuproxy.org/(request|offer)/{payload} and instead sends the payload data\nto the copypaste instance in the core.\n\nThe actual handling of the tab interception is done in browser-specific\nareas while the parsing is handled in the generic_ui component.\n\nFor Chrome, when the request is intercepted, the tab is redirected to\nshow the standard app interface.  This behaviour can be a bit odd (e.g.\nif the app is already open), however, it seems equally as good as the\nalternative of showing a landing page just indicating that the url is\nloaded.\n\nFor Firefox, no action is taken on the request and the UProxy window is\nopened.","distinct":true,"url":"https://api.github.com/repos/uProxy/uproxy/commits/853766f773b340f6ad335999f3ed65c572e4d5a2"}]}