306684 - Viewport relative layout of SVG isn't possible in moz

Status: NEW

(Core :: SVG, defect)

Description

[Jonathan Watt [:jwatt]]

Comment 1

[Jonathan Watt [:jwatt]]

It isn't possible for scripts in SVG content to determine the position and size
of their viewport, so they can't position or size parts of their image
accordingly. For example you may want to put a menu against the right hand side
of the viewport. Furthermore if the size of the viewport changes we don't
currently dispatch SVGResize events, so content has no way to correct for these
changes.

Comment 2

[Jonathan Watt [:jwatt]]

Attachment: patch to dispatch SVGResize DOM events

Comment 3

[Jonathan Watt [:jwatt]]

Comment on attachment 198225 [details] [diff] [review]
patch to dispatch SVGResize DOM events

Oops. I meant SVGResize DOM events of course.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 198225 [details] [diff] [review]
patch to dispatch SVGResize DOM events

Don't you want to only dispatch an event if the size actually changes?

I wonder if you should dispatch it on a timer, I know we do that for resize
events for the top windows. In any event you probably want to keep track of if
there currently is an event pending and not dispatch a new one until it has
been handled.

You should put the refcount stuff in DestroySVGResizePLEvent rather then
HandleSVGResizePLEvent. Right now you'll leak the node if you early-return or
if the event gets cancled for one reason or the other. Another solution which
IMHO is cleaner is to subclass PLEvent and put an nsCOMPtr as member to do the
refcounting for you. See for example
http://lxr.mozilla.org/mozilla/source/docshell/shistory/src/nsSHEntry.cpp#685

Comment 5

[Jonathan Watt [:jwatt]]

*** Bug 320268 has been marked as a duplicate of this bug. ***

Comment 6

[Jonathan Watt [:jwatt]]

Attachment: patch to implement .viewport property

Comment 7

[Boris Zbarsky [:bzbarsky]]

The x/y values there look wrong for the outer case.

Not to mention that the !presshell test is backwards....

Might be worth writing some tests for this.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Also, that's not live, but doing that could be hard.

Comment 9

[Jonathan Watt [:jwatt]]

...and the members of the SVGRect should be readonly. *sigh*

Why do the x/y values look wrong for the outer case? I think in this case x and y should be the offset of the <svg>'s content area from its bounding box. Isn't that what GetContentRect gives me?

Comment 10

[Boris Zbarsky [:bzbarsky]]

GetContentRect() gives the rect in the coordinate system of the parent frame.  So if you have:

  <span><svg:svg/></span>

it'll give coordinates relative to the span.

Assuming that http://www.w3.org/TR/SVGMobile12/svgudom.html#svg__SVGSVGElement_viewport is the right thing to be reading, this text looks relevant:

  If this SVG document is embedded as part of another document (e.g., via the
  HTML 'object' element), then the position and size are unitless values in the
  coordinate system of the parent document. (If the parent uses CSS or XSL
  layout, then unitless values represent pixel units for the current CSS or XSL
  viewport, as described in the CSS2 specification.) 

I'm not sure what to make of that next sentence, though:

  If the parent element does not have a coordinate system, then the user agent
  should provide reasonable default values for this attribute.

Might want to check with the WG...

Comment 11

[Jonathan Watt [:jwatt]]

Oh, that's where you got the "live" from. I was reading it from the SVG 1.1 section (linked in the URL field of this bug) and therefore thought you'd just implied that it was live from the fact that it's readonly.

So your description of GetContentRect is how I understood that method to work, I just misinterpreted the spec. I'm actually not sure how to get the offset of an element from its "CSS viewport". Hmm...

Comment 12

[Boris Zbarsky [:bzbarsky]]

Oh.  I'd tried to find that text in 1.1 and failed...  Thanks for the pointer!

So the 1.1 definition seems to be assuming that there is no inline SVG, ever, right?  As I see it, there are three cases to look at:

1) <svg> whose parent is an SVG element (inner SVG).  There's no problem here,
   as far as I can tell: use the coordinate system of that parent.  Of course
   Tiny 1.2 doesn't cover this case.
2) <svg> whose parent is not an SVG element (outer SVG, possibly inside a
   foreignobject).  Not sure what the "right" behavior here is.
3) <svg> which is the root element.  There's an embedding <object>.  Need to
   look at that <object>s frame or something?

It might be worth asking the WG for clarification here just to make sure we're on the right track.

Comment 13

[Boris Zbarsky [:bzbarsky]]

I should also note that it's not clear that the <object> case would support the use case this bug is filed on, if I understand the spec...