Last Comment Bug 579853 - Canvas element inside defs elements are not rendered
: Canvas element inside defs elements are not rendered
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: SVG (show other bugs)
: unspecified
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 593266 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-19 02:59 PDT by Jeremie Patonnier :Jeremie
Modified: 2010-09-02 22:49 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (2.22 KB, image/svg+xml)
2010-07-19 03:02 PDT, Jeremie Patonnier :Jeremie
no flags Details
Simpler testcase (1.65 KB, image/svg+xml)
2010-07-19 04:24 PDT, Jeremie Patonnier :Jeremie
no flags Details

Description Jeremie Patonnier :Jeremie 2010-07-19 02:59:31 PDT
User-Agent:       Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100718 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100718 Minefield/4.0b2pre

while I'm still working around 'defs', 'foreignObject' and 'use', I have found this strange behaviour.

If you set a 'canvas' element inside a 'foreignObject', itself inside a 'g' element and if you paint some things on the canvas, it works well. But if you do the same and put the 'g' element inside a 'defs' element, when you call the 'g' element trough the 'use' element, the canvas element is never rendered.

If you use an HTML img element in replacement of the canvas element, it work well.

Reproducible: Always

Steps to Reproduce:
1. Open the test case
 
Actual Results:  
You can see 3 green squares and 1 red square.

Expected Results:  
You should see 4 green squares
Comment 1 Jeremie Patonnier :Jeremie 2010-07-19 03:02:59 PDT
Created attachment 458294 [details]
testcase

The first square is using a rect and act as a reference redering
The second square use an HTML img
The third square use a canvas element outside the defs element
The fourth square use a canvas element inside the defs element
Comment 2 Jeremie Patonnier :Jeremie 2010-07-19 04:24:52 PDT
Created attachment 458312 [details]
Simpler testcase

I have run some more tests and 'defs' is not the issue. I think the issue is based on how 'use' handle it's rendering zone with 'canvas'.

This simpler test case remove the 'defs' element and focus on 'use'.

The left column show how it behave with 'canvas' the right column show how it behave with 'img';

Note that in this test case, the 'use' element is affected by bug 578309
Comment 3 Jeremie Patonnier :Jeremie 2010-07-19 04:45:26 PDT
Ok, sometimes I'm dull! Forget about 'use' and bug 578309. This has nothing to do here. Sorry.

But the problem of not rendering canvas vs. rendering HTML img remain.
Comment 4 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-07-19 08:48:42 PDT
<use> clones the elements it references, in the cloneNode sense (or must act as if it does).  It says so right in the spec (SVG 1.1 second edition, section 5.6):

  The effect of a ‘use’ element is as if the contents of the referenced element
  were deeply cloned into a separate non-exposed DOM tree which had the ‘use’
  element as its parent and all of the ‘use’ element's ancestors as its
  higher-level ancestors.

For an <img>, cloning clones the src attribute, so the clone also loads the image.

For a <canvas>, cloning clones attributes but does NOT clone the actual backing store.  So you don't see the image.

Similarly <input> elements with text typed in would not show that text when <use>d, etc.  <use> works on the DOM level, so it doesn't faithfully represent data that's not part of the DOM.
Comment 5 Jeremie Patonnier :Jeremie 2010-07-19 10:00:12 PDT
Ok, so I supposed that if the cloned DOM tree is non-exposed, it means that there is no way of accessing the cloned Canvas. Is that right?

Because the SVG spec is a bit old and the HTML5 spec is really new, it looks to me that this particular use case is something that no one imagine in the early time of SVG.

Now that HTML5 allow to use direct inline SVG inside the HTML dom tree, there is maybe something to discuss with the HTML and SVG working group here?

I can see some others use cases that could handle the same "problem". All the forms element as Boris mentions or some video usage. For example, if I defined a video element and that I attach some control to it through Javascript. If I reused that video element through the 'use' element, the Javascript controls only match the first element, not both. Sometimes it's require, sometimes it's not. As a user, if I want to build separate controls, it makes sens to clone myself the video element. But if I want a unified control system for all my clone, it would be very intuitive to use the 'use' element to perform a "fake" cloning.

I agree that for standalone SVG document, the way the 'use' element is defined make sens : it's impossible to imagine all the use case that foreignObject could bring and its necessary to have a reasonable behavior on that matter.

But when we talk about SVG and HTML5 so intimately mixed, for what is worth, I think it would be interesting to go further. Sadly, I'm just a "end user" so I have no skills nor ideas on how is it possible to achieve this, but I'm pretty sure that there will be a lot of web designers that enjoyed such a possibility.
Comment 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-07-19 10:26:25 PDT
> it means that there is no way of accessing the cloned Canvas

There's no way to access the canvas api parts of it, correct.

> it looks to me that this particular use case is something that no one imagine
> in the early time of SVG.

Probably.  Most of <foreignObject> isn't all that well thought out.

> there is maybe something to discuss with the HTML and SVG working group here?

Sure.  public-html@w3.org and www-svg@w3.org respectively.
Comment 7 Robert Longson 2010-09-02 22:49:39 PDT
*** Bug 593266 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.