Previous code was importing nodes from the XHR result into current document, then pulling text content of what might be the right element, then concat'ing that straight into HTML. Eww! Now pulling the text content straight from the XHR result -- same element that we check for existence of -- and using jQuery's own text() to do the getting and setting of text. Also note that some browsers might have been pulling HTML instead of text, or other funkiness.
This uses the 'copy' and 'paste' DOM events to trigger a counter update. I haven't had a chance to 100% confirm that middle-button click on X11 triggers the event, but it ought to.
Cut and paste events from context menu and main edit menu known good in:
* Firefox 4.08b-pre
* IE 9 preview 7
* IE 8 current
* Chrome 8 beta current
* Safari 5.0.3
Opera is listed as not supporting these events, oh well.
Note that using a *delete* command from a menu doesn't trigger an event. Sigh, you can't win everything.
The Meteor realtime plugin sets document.domain to the common prefix between the main server and the Meteor server's hostnames, which overrides the same-origin controls on JavaScript DOM access so the two parts of the app can speak to each other.
This unfortunately causes "fun" side effects for XMLHTTPRequest access to the main domain... if the new domain doesn't match the actual host (eg 'status.net' instead of 'brion.status.net') then we can't access the XHR's responseXML attribute, which holds a DOM tree of the parsed XML return data.
As a workaround, if we can't get at the contents there, we'll parse a fresh DOM tree in the local context from the responseText property, which remains available.
In the longer term, recommend retooling the realtime stuff so it's not fiddling with document.domain. It could also be an issue as it could allow local JavaScript XSS attacks to migrate to subdomains in other open windows.
