Adobe "wonder" demo is missing animated orangish block in left foreground

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: dholbert, Assigned: longsonr)

Tracking

({regression})

Trunk
x86
Linux
regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
In recent mozilla-central nightlies, the Adobe SVG "wonder" demo has been missing the orange-ish block on the front.  In fact, I think we're not displaying this 
element at all:
  http://www.adobe.com/svg/demos/animClippath/images/wndw.jpg

Regression range:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a3pre) Gecko/20100301 Minefield/3.7a3pre
http://hg.mozilla.org/mozilla-central/rev/e7970f6c7cdd

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a3pre) Gecko/20100302 Minefield/3.7a3pre
http://hg.mozilla.org/mozilla-central/rev/ba77049941c3

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e7970f6c7cdd&tochange=ba77049941c3

There are a few SMIL changes in that range, but Bug 547062 looks more suspicious to me, given the use of clipPath in the broken document.

Here's a snippet of the broken document (with whitespace cleaned up, for readability):
> <g id="maskedPict2" style="&st2;">
>   <g>
>     <clipPath id="aiclp2" style="&st0;">
>       <rect x="98" y="0" width="5" height="300"/>
>       <animateTransform attributeName="transform" type="translate" values="0 0;-20 0;-90 0;0 0"
>                         calcMode="spline" keyTimes="1;7;9" keySplines="0 .5 .25 .5;.2 0 .75 0"
>                         additive="sum" dur="10s" repeatDur="indefinite"/>
>       <animateTransform attributeName="transform" type="scale"  values="0.25 1;3 1;0.5 1;1 1"
>                         additive="sum" dur="9s" repeatDur="indefinite"/>
>     </clipPath>
>     <g style="&st4;">
>       <image x="0" y="-5" width="400" height="310"
>              xlink:href="http://www.adobe.com/svg/demos/animClippath/images/wndw.jpg" />
>     </g>
>   </g>
> </g>
(Reporter)

Comment 1

8 years ago
(In reply to comment #0)
> There are a few SMIL changes in that range, but Bug 547062 looks more
> suspicious to me, given the use of clipPath in the broken document.

Confirmed -- if I revert Bug 547062's patch (with "hg export ba77049941c3 | patch -R -p1"), I see chunks of orange from wndw.jpg again.  (It still is slightly broken, though -- the "wndw.jpg" slices don't seem to repaint automatically, until something else moves across them.  This makes them look "frozen" for periods of time.  That may be a regression from a more recent change.)
Blocks: 547062
(Assignee)

Comment 2

8 years ago
http://www.w3.org/TR/SVG/masking.html#EstablishingANewClippingPath

A 'clipPath' element can contain 'path' elements, 'text' elements, basic shapes (such as 'circle') or a 'use' element. 

!ENTITY % SVG.clipPath.content is not consistent with this and allows animation and description so I guess those should be allowed too although the content list should be made consistent in the specification.
(Assignee)

Updated

8 years ago
Assignee: nobody → longsonr
(Assignee)

Comment 3

8 years ago
Created attachment 433308 [details] [diff] [review]
one way

This is one way to do it.
(Assignee)

Comment 4

8 years ago
Created attachment 433311 [details] [diff] [review]
better patch

This seems much better though.
Attachment #433311 - Flags: review?(dholbert)
(Reporter)

Comment 5

8 years ago
Comment on attachment 433311 [details] [diff] [review]
better patch

Looks good to me.  Could you add a reftest for good measure?

I verified that this patch fixes the bug, though I still get the (new) repaint issues described in comment 1... I guess that's a separate issue that regressed while this was broken.  I'll file a separate bug on that.
Attachment #433311 - Flags: review?(dholbert) → review+
(Reporter)

Comment 6

8 years ago
(filed Bug 553416 on the new repaint issue)
(Assignee)

Comment 7

8 years ago
Comment on attachment 433311 [details] [diff] [review]
better patch

asking for SR since this touches a number of modules even though it's fairly straightforward.
Attachment #433311 - Flags: superreview?(roc)
(Assignee)

Comment 8

8 years ago
I'll add a reftest before landing too. A clipPath with an empty animateTransform should do.
Attachment #433311 - Flags: superreview?(roc) → superreview+
(Assignee)

Updated

8 years ago
Attachment #433308 - Attachment is obsolete: true
(Assignee)

Comment 9

8 years ago
checked in http://hg.mozilla.org/mozilla-central/rev/e2c79d3c12f7
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.