Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Nov 8, 2012, at 2:15 AM, Elliott Sprehn <esprehn@gmail.com> wrote:

> 
> On Thu, Nov 1, 2012 at 6:43 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> 
> On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> ...
> >
> > For example, being able to re-render the page manually via DOM
> > inspection and custom <canvas> painting code.  Google Feedback does
> > this, for example.  If shadows are only exposed when the component
> > author thinks about it, and then only by convention, this means that
> > most components will be un-renderable by tools like this.
> 
> As Adam Barth often points out, in general it's not safe to paint pieces of a webpage into <canvas> without security/privacy risk. How does Google Feedback deal with non-same-origin images or videos or iframes, or with visited link coloring, to cite a few examples? Does it just not handle those things?
> 
> 
> We don't handle visited link coloring as there's no way to get that from JS.
> 
> For images we proxy all images and do the actual drawing to the canvas in a nested iframe that's on the same domain as the proxy.
> 
> For cross domain iframes we have a JS API that the frame can include that handles a special postMessage which serializes the entire page and then unserializes on the other side for rendering. Thankfully this case is extremely rare unlike web components where it turns out you end up with almost the entire page down in some component or another (ex. <x-panel>, <x-conversation-view> …). This of course requires you to have control of the cross origin page.
> 
> For an architectural overview of Google Feedback's JS HTML rendering engine you can look at this presentation, slides 6 and 10 explain the image proxy:
> 
> http://www.elliottsprehn.com/preso/fluentconf/

Are these types of workarounds adequate for the web components case? If not, why not?

Regards,
Maciej