486028 - support dynamic personas

Status: RESOLVED INCOMPLETE

(Mozilla Labs Graveyard :: Personas Plus, defect, P2)

Description

[Myk Melez [:myk] [@mykmelez]]

The Personas extension should support dynamic personas that can change over time, since that opens up many interesting artistic possibilities for styling chrome.

Last year we implemented a version of dynamic personas that rendered web content personas in a content iframe in the hidden window, took periodic snapshots of the content using a canvas, and placed the snapshots underneath the chrome via CSS background images.

We removed that later to simplify the server implementation and make it more scalable (which will be an issue with any solution that uses web content).  The other significant issue was that it wasn't very dynamic, since personas would only "paint" to the chrome background once per minute.  And it was fairly complex.

Ideally, we'd like to be able to support full web content personas that paint as quickly as they change.

One way to implement this would be to place content iframes underneath the chrome, then load web content personas into them.  This approach is currently blocked on integration of the chrome and content view managers/trees (bug 130078).

A second way to implement this would be to render web content personas in a content iframe inside an SVG image (like on <http://starkravingfinkle.org/blog/wp-content/uploads/2007/07/foreignobject-transform.svg>) that is set as the CSS background image for the chrome; or, alternately, simply support SVG image personas that can choose to load web content via a foreignObject element.  This approach is blocked on the ability to use SVG images as CSS background images (bug 231179).

A third way to implement this would be to render web content personas in a content iframe in the hidden window, place an SVG image containing a foreignObject element underneath the chrome, and then set the background of the foreignObject element to the content iframe, as depicted in slide 70 of this presentation <http://www.xdraw.org/CSS_slides/> and utilizing SVG external document references <https://developer.mozilla.org/web-tech/2008/10/10/svg-external-document-references/>.

If I understand correctly, this approach is blocked on the ability to use "SVG paint servers (gradients and patterns) for non-SVG content, via CSS background-image", as mentioned in roc's SVG Bling Update blog post <http://weblogs.mozillazine.org/roc/archives/2008/10/svg_bling_updat.html>.

A fourth way to implement this would be remove SVG from the third approach and directly set the background of the chrome to the content iframe.  If I understand it correctly, this approach is blocked on the ability to "use any element as a CSS background-image", as mentioned in that same blog post.

cc:ing roc, as I'd love to hear his thoughts on additional options, which one is optimal, and which is going to become possible the soonest.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Using an SVG image as a CSS background image in chrome is probably the best approach. I have assigned SVG images to myself as my feature for 1.9.2. Having a Firefox feature depending on it will definitely make it more likely to get in :-). What schedule to do you need?

Of your other options, full view manager integration is definitely further out (although we will make progress in that direction). Using SVG paint servers would work but I'm not motivated to land that on trunk, SVG images are cross-browser and cover almost all the use cases. "Use any element as a CSS background image" would be interesting but needs some API changes so is probably quite far out.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #1)
> Using an SVG image as a CSS background image in chrome is probably the best
> approach. I have assigned SVG images to myself as my feature for 1.9.2. Having
> a Firefox feature depending on it will definitely make it more likely to get in
> :-). What schedule to do you need?

mconnor has been looking into uplifting Personas into the next version of Firefox after Shiretoko (i.e. whatever the current trunk ends up becoming).  It would be fantastic to support dynamic personas for that release.

Ideally we'd be able to experiment with and test dynamic personas in a version of the extension running on nightly builds even before uplift, and if we take the approach of using SVG images as CSS background images, then no work is required in the extension itself, but we'll have to do some work on the server, the difficulty of which depends on the extent to which ImageMagick supports SVG (the server uses ImageMagick to enforce guidelines on the size of contributed persona images and generate thumbnails of them).

If ImageMagick fully supports SVG images like http://starkravingfinkle.org/blog/wp-content/uploads/2007/07/foreignobject-transform.svg, then supporting SVG on the server should be easy.

One concern: I noticed that the plan for SVG in <img> tags precludes the execution of script (bug 276431, comment 58).  Presuming the same is true for SVG loaded via CSS, that's suboptimal from a functionality standpoint (although good for security).

Nevertheless, I think it's probably ok for this use case as long as foreignObject still works and can load HTML files with script that does get executed (with content privileges, even though the SVG image itself is being loaded in chrome).

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Hmmm ... doing the script in an IFRAME *might* work, I'm not sure how well it would though.

You can experiment with this today. Instead of using an SVG <img> or CSS background image, use an <svg> element and fill it with a pattern which is in an external document. Put an iframe in that external document and see what happens.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #3)
> You can experiment with this today. Instead of using an SVG <img> or CSS
> background image, use an <svg> element and fill it with a pattern which is in
> an external document. Put an iframe in that external document and see what
> happens.

My SVG fu is weak, so I might misunderstand, but I think bug 486240 prevents me from conducting this experiment, since it hangs the browser when I use an <svg> element that fills a shape with an iframe embedded in an SVG pattern in an external document.

Comment 5

[Suneel]

marking this a P2, though priority may be bumped up if we decide this is a critical feature for uplift.