On Nov 8, 2012, at 2:15 AM, Elliott Sprehn <espr...@gmail.com> wrote:
> > On Thu, Nov 1, 2012 at 6:43 AM, Maciej Stachowiak <m...@apple.com> wrote: > > On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. <jackalm...@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
