brianmcd / cloudbrowser Goto Github PK

Thoughts:

• Could compress on the fly with a lookup table
• Should be toggleable.

I ♥ Be Famous And 29 It A Great Feeling

If we call this, it prevents subsequent events from being generated as a result of the current one. For example, if a keydown event fires and preventDefault is called, then the browser won't generate the keypress and keyup events.

Toggle-able, multi-level logging infrastructure.

Should be able to write to log file or stdout/stderr.

e.g. onload, onclick, etc.

As per: http://blog.chromium.org/2011/08/new-websocket-protocol-secure-and.html

The WebSocket protocol has been updated again. DNode uses an older version of socket.io for websockets, and that version doesn't support the new protocol. Newer versions of socket.io do support it, and offer an event driven API that gives similar functionality as DNode.

Issue: wait for substack to fix dnode, fix dnode ourselves, or replace dnode with our own protocol on top of the newest socket.io? The newest socket.io has API breaking changes, so simply changing dnode's package.json doesn't work.

Instead of simulating it on the client, we should probably simulate it on the server. We can basically move the client code over.

If we have something like

<a href='something>

I'm trying to get CloudBrowser minimally running on CentOS 6.4. It isn't obvious what the relevant steps are, so I'm discovering them by trial and error.

Having < in a t ext string breaks the parser. This applies to attributes and script text blocks.

Need access control for browsers:

• Restrict based on shared password.
• Restrict based on OpenID username (assuming we can get that info).

Need different permission levels for clients on a browser:

• Read-only: can view a co-browsing session, but events from that client aren't sent to server.
• Read-write: can view a co-browsing session, and events from that client are sent to the server.

Do this using clicks and with manually setting window.location in code. I think there might be an issue with how we bail out of the "previous" DOM when we set window.location to navigate an existing page.

Integrated with OpenID.

Allow users to create private or public browsing instances.

• users could specify specific e-mail addresses for private instances if we can get that info from an openID login.

Allow users to run a sample app.

It looks like the issue with emitting script node early is fixed: codders/html5@77cc8b0

@import statements in CSS can use relative URLs, but the ResourceProxy doesn't handle this. This causes jQuery UI demos to break, for example.

We need to parse the @import rules and re-write the CSS to use ResourceProxy URLs.

CSSOM can do some stylesheet processing, so we might be able to employ that.

When running the jQuery test suites, if you click "Hide passed tests", it doesn't do anything on the first click, but then works as expected after that.

It also doesn't draw the X in the checkbox on the client, no matter what.

Once inline handler patch lands, skip them in DOM serializer and setAttribute advice.

Test iframe, script, and inline handler serialization.

This might work for things like the YUI3 slider that require CSS positions that we can't calculate on the server.

We want to be able to save a Browser Instance, shut down the server, then come back later and restore everything.

Initial thoughts:

• Serialize the DOM and save that snapshot.
• Require scripts to export a save() method if that have state that needs to be restored. It should return an object that can be JSON.stringify'd and saved to a database.
• Require scripts to export a restore() method that takes the return value from save and gets the script into the correct state.
• Scripts that don't export save or restore just get re-run. Support libraries should be fine with this (like jQuery).

https://github.com/jbaron/htmlscanner

C++ implementation, claims to be fast. It doesn't look like it would be too hard to hook this into jsdom.

The .gitmodules file refers to url = [email protected]:jquery-cloudbrowser.git, which breaks make setup for people without access to theta.cs.vt.edu.

$ make setup
git submodule update --init
Submodule 'deps/jquery-cloudbrowser' ([email protected]:jquery-cloudbrowser.git) registered for path 'deps/jquery-cloudbrowser'
Initialized empty Git repository in /vagrant/cloudbrowser/deps/jquery-cloudbrowser/.git/
The authenticity of host 'theta.cs.vt.edu (128.173.237.152)' can't be established.
RSA key fingerprint is 86:35:2e:1f:c6:f9:93:f7:d2:7c:3e:17:ea:c1:c2:29.
Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'theta.cs.vt.edu,128.173.237.152' (RSA) to the list of known hosts.
[email protected]'s password:   C-c
make: *** wait: No child processes.  Stop.
make: *** Waiting for unfinished jobs....
make: *** wait: No child processes.  Stop.

I currently ignore this.

Need to handle delete/backspace.

It would be nice to be able to run the jQuery test suite from the command line using a simulated TestClient.

This will be required to get decent performance, since things like parsing HTML are large, blocking operations in JSDOM.

The BrowserManager will turn into a more important class, keeping track of a bunch of pipes most likely.
We might need to use something like redis to handle communication with the browsers, server, and clients.

We support a very limited number of properties on the style attribute. JSDOM doesn't have great support for it, so this will take some work.

http://dev.w3.org/csswg/cssom/#cssstyledeclaration

Sometimes we get nothing instead of an exception.

Need to share the Location implementation between document and window. We currently only have it on the window. Should be a quick fix (maybe just defining getter/setter on document to proxy to window).

The knockout unit tests rely on document.write inserting HTML in place. JSDOM doesn't do this, and it causes scripts to execute in the wrong order.

Current hack-fix is to remove the script injection to get knockout tests to run.

Need to have automated tests for handling things like clicks on the client side.

We should be able to switch between node-htmlparser and HTML5 easily.

When we run into errors, we should catch/report exceptions instead of crashing the server. Combing with the back/forward button, this should lead to much more robust co-browsing.