chromeless-kit package / canvas-proxy module implementation

[taboca]

The canvas-proxy module, which is exposed to the HTML browser page, so far allows capture of a contentWindow ( iframe window for example ) to a canvas. We should make this implementation offer more options to developers, and also to pass events to the referenced browser.

• Take screenshots in different sizes and aspect ratio
• Send click events to the referenced browser
• Send keyboard events to the referenced browser

A reference work here is in Fennec code

[taboca]

This works in theory but the problem I had is that when an iframe is out the screen, it does not render drawWindow. We may need to find a way to force the hidden browser.

[taboca]

Experimental canvas-proxy updated in branch https://github.com/mozilla/chromeless/tree/canvas_mediator_browser

Example ./tests/canvas_browser/index.html shows a grayscale-based browser:

• cannot DOMMouseScroll ( yet )
• cannot click in text fields ( try to use tab key )
• you can access Gmail full
• No API events yet, for the developer, such as progress of page load.
• Uses a XUL Stack pattch over the ./modules/internal/chromeless-sandbox-window.js

This is slower than a full browser but I may end up using this as a solution for a production browser in case I get all the events and no major events blockers. This design is a bit inspired in an older version, a very very old prototype I made while in Minimo days ( right before Fennec ) where we had a sort of panorama demo ( user could see all browsers from a pagewith canvas ). The moving forward here, an option, could be to simply follow an approach to make the canvas to be associated with a browser that resides in another process. Then while it could be a bit slower ( routing things ) it would also offer a few benefits.

[taboca]

Need a review from Lloyd. What I want here is to land this patch #108, that is basically 2-3 lines, to the chromeless-sandbox-window. This patch would allow the experimental module ( canvas-proxy.js ) to add hidden Browsers. The patch creates a container there, a XUL stack which I don't think would damage the other cases.

I also think the whole menu stuff should be added in this redesigned model of organization. With that, we could keep chromeless-sandbox-window cleaner, and all the XUL additions would come out from specific modules/packages. So, for example, if you require("menu") you would know the menu added things in there, otherwise the whole logic is not needed.