Closed Bug 787837 Opened 10 years ago Closed 9 years ago

Visual artifacts when animating "d" on a path element, with <g filter>


(Core :: SVG, defect)

Not set





(Reporter: dholbert, Unassigned)



(Keywords: regression, testcase)


(1 file)

Attached image testcase 1
 1. Load attached testcase

EXPECTED RESULTS: No visual artifacts 
ACTUAL RESULTS: Visual artifacts are left trailing behind the "L" as it moves (both above it, when it's moving down, and below it, when it's moving up)

I get EXPECTED RESULTS in release:
  Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0
but ACTUAL RESULTS in nightly:
  Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/18.0 Firefox/18.0
  Built from
NOTE: The testcase has a filter on a trivial <g> element that's the parent of the <path>.

If I move the filter to the <path> element itself (instead of the <g>), then I get EXPECTED RESULTS.
Summary: Visual artifacts when animating "d" on a path element → Visual artifacts when animating "d" on a path element, with <g filter>
Mozregression gives me these regression ranges on m-c & m-i:

Last good nightly: 2012-07-03
First bad nightly: 2012-07-04

Last good nightly: 2012-07-03
First bad nightly: 2012-07-04

The main thing in there is the DLBI backout, so I'm tentatively assuming that caused this... but that's an odd culprit, because it was a *backout*, and I don't think this was a problem before DLBI landed originally (e.g. in our current release, Firefox 15, per comment 0).

It could be that this broke on trunk (but had no visible effects) while DLBI was in, and then became exposed when DLBI backed out.  Or, it could be that this is from a mis-resolved merge conflict in the backout patches.

Regardless -- if this was "caused by" that backout in some sense, that does mean this'll likely become WORKSFORME when DLBI re-lands, which is good.
Keywords: testcase
This seems to been caused by bug 738192 since it first appears in 2012-06-25-03-05-37-mozilla-central actually. I suspect that DLBI simply hid the issue by over invalidating, which is a concern in itself.
Blocks: 738192
OS: Linux → All
Hardware: x86_64 → All
This seems to be WFM now, and paint flashing shows no over invalidation. Can you check it's WFY, Daniel, and close if so?
Closed: 9 years ago
Resolution: --- → WORKSFORME
Fixed by this cset, from bug 796847:
A targeted build from that cset is WFM, but a targeted build from the previous cset (3edb5bb92461) exhibits the bug.
Depends on: 796847
You need to log in before you can comment on or make changes to this bug.