378923 - Make non-root outer-<svg> respect |overflow:visible| (overflow="visible")

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[tor]

Attachment: testcase - should show circle outside square, with moveover effects

Right now nsSVGOuterSVGFrame always clips to the provided area, so the overflow region isn't shown even when overflow:visible is set.

Comment 1

[tor]

Attachment: half fix

This fixes the rendering of the overflow region, but it looks like we need to implement overflow region logic in nsSVGOuterSVGFrame (calling FinishAndStoreOverflow?) in order to get events for the overflow area.

Comment 2

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

nsSVGOuterSVGFrame needs to set aDesiredSize.mOverflowArea to its bounding-box. This probably means that you'll need to detect bbox changes and trigger an incremental reflow if the before-bbox or the after-bbox overflows.

Comment 4

[Robert Longson [:longsonr]]

See also bug 490003 comment 13 and bug 490003 comment 14

Comment 5

[Jonathan Watt [:jwatt]]

I'll fix this after bug 769645.

Comment 6

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

Should overflow:scroll and overflow:auto work on outer <svg>? If so, we should just construct nsHTMLScrollFrames for outer <svg>s if necessary.

Comment 7

[Ben]

@Robert: According to the spec: http://www.w3.org/TR/SVG/masking.html#OverflowProperty

Auto: "Within SVG content, the value auto is equivalent to the value visible."  Scroll: " if the ‘overflow’ property has the value hidden or scroll, the effect is that a new clipping path in the shape of a rectangle is created." So, in both cases, yes.

It looks like this bug just celebrated its fifth anniversary (!). Any timetable on fixing this?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Ben: the question in comment 6 is whether there should be scrollbars, not just clipping.

Comment 9

[Ben]

Understood. Again, the spec seems clear that for <svg> inside an html document, all of the CSS2 clipping rules apply, including "scrollbar or panner" behavior. What other interpretation would give meaning to the "scroll" value as it's described?

Comment 10

[Boris Zbarsky [:bzbarsky]]

What the spec says is:

  When an outermost svg element is embedded inline within a parent XML grammar which uses
  CSS layout ([CSS2], chapter 9) or XSL formatting [XSL], if the ‘overflow’ property has
  the value hidden or scroll, then the user agent will establish an initial clipping path
  equal to the bounds of the initial viewport; otherwise, the initial clipping path is set
  according to the clipping rules as defined in CSS2 ([CSS2], section 11.1.1).

which says nothing about whether there should be scrollbars; it just talks about the clipping path.  That's all it says about the matter.  So an obvious interpretation is that that "scroll" sets the clip path and that's it.  Whether this is intended or even desirable is a separate issue.  That depends on what web content is doing and what other UAs are doing much more than on what an underdefined and vague spec says.

Comment 11

[Ben]

Boris: You're definitely right that the spec could be clearer on the "scroll" question, but I don't it's fair to use that as a rationale for not implementing the parts that are perfectly clear, which include {overflow: "visible"} being respected.

As for "intended or desirable", whose intention are you talking about? As far as I'm concerned, if it's in the spec and I code it expecting it to work, it's "desirable." Here are some use cases where <svg> overflow is desirable in a layout:

http://stackoverflow.com/questions/1572587/allow-svg-graphics-to-overflow-outside-the-containing-svg-element

http://stackoverflow.com/questions/12326838/overflow-visible-on-svg

Comment 12

[Boris Zbarsky [:bzbarsky]]

> but I don't it's fair to use that as a rationale for not implementing the parts that are
> perfectly clear

No one is arguing that.  You were responding to comment 6, which was asking how "scroll" should work and had nothing to do with "visible".

> As for "intended or desirable", whose intention are you talking about?

The spec's.  Specs can be wrong, and often are....

Comment 13

[Robert Longson [:longsonr]]

(In reply to Ben from comment #11)

> http://stackoverflow.com/questions/1572587/allow-svg-graphics-to-overflow-
> outside-the-containing-svg-element
> 
> http://stackoverflow.com/questions/12326838/overflow-visible-on-svg

Either of those use cases can be solved by making the container bigger. That's why overflow on the outer <svg> element is low priority because there's generally an easy workaround.

On the off chance it's something you want to help fix, I'm more than happy to provide hints, tips and code reviews.

Comment 14

[Jonathan Watt [:jwatt]]

Attachment: patch

Comment 15

[Jonathan Watt [:jwatt]]

Bug 875175's fix added in children's visual overflow to the nsSVGOuterSVGFrame (where appropriate). This patch depends on that.

Comment 16

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

Comment on attachment 753770 [details] [diff] [review]
patch

Review of attachment 753770 [details] [diff] [review]:
-----------------------------------------------------------------

great! Needs a reftest though :-)

Comment 17

[Jonathan Watt [:jwatt]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6f025261b40d

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #16)
> great! Needs a reftest though :-)

I added...seven. ;)

Comment 18

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/6f025261b40d