Bug 117655 – Javascript Animation playing through layers of background SVG

• Component: SVG
• Status: RESOLVED WONTFIX

[Nick]

Chromium bug https://code.google.com/p/chromium/issues/detail?id=241328- affects Safari 7 and iOS7 Safari

What steps will reproduce the problem?

1.  Visit https://create.passkit.com click on any one of the 5 pass type images
2.
3.

What is the expected result?

jQuery slideToggle should quickly hide the image in the simulated phone window and a new image should slowly toggle back within the bounds of the iPhone window.  Has been working in v25 and earlier versions of Chrome, still working on Chrome for iPhone and all other major browsers.

Successful webkit result can be seen by visiting the same page in Safari 6, Firefox 20 or IE 10.

What happens instead?
jQuery animation plays slowly, not completing but still triggering the onComplete slideToggle.  The replaced image is peculiarly rendered and animated outside the bounds of it's parent container and in between 2 layers of a background SVG image (https://d1ye292yvr7tf6.cloudfront.net/images/iphone.svg - the title bar of this image is a transparent gradient). 


Please provide any additional information below. Attach a screenshot if
possible.
On the attached image, you can see the outline of a background object (white rectangle with rounded corners) between the black background layer and transparent overlay of a background SVG image - the entire object should not be rendered outside the bounds of it's parent and certainly should not appear between layers of an independent SVG image.

[Radar WebKit Bug Importer]

<rdar://problem/14160785>

[Joseph Pecoraro]

The chromium bug had supposedly narrowed it down to this WebKit range 141440:141478:
<http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=%2Ftrunk&range=141440%3A141478&mode=html>

[Joseph Pecoraro]

Doing my own bisecting I see it breaking with r138184:
<http://trac.webkit.org/log/trunk/?rev=138184&stop_rev=138184>

  Implement CSS parsing for CSS transitions unprefixed.
  ​https://bugs.webkit.org/show_bug.cgi?id=104804
  <http://trac.webkit.org/changeset/138184>


@Nick, it looks like the CSS on the page is accidentally too broad when unprefixed transitions are supported. This snippet of CSS:

    #pass, #back, details, .animate {
        -webkit-transition: -webkit-transform .7s linear;
        -moz-transition: -moz-transform .7s linear;
        -o-transition: -o-transform .7s linear;
        transition: all .7s linear
    }

Now that some browsers (Safari / Chrome) support unprefixed transition, the page went from transitioning only "-webkit-transform" to transitioning "all" properties, which is producing the unexpected results. You should update the content to better handle the case where transition is supported unprefixed. For example, making this "transition: -webkit-transform .7s linear" the animation behaves as expected.

This case is a little tricky, since "transition" is supported unprefixed, but it doesn't look like "transform" is supported unprefixed yet. I suppose you could go with:

    #pass, #back, details, .animate {
        /* Vendor prefixed */
        -webkit-transition: -webkit-transform .7s linear;
        -moz-transition: -moz-transform .7s linear;
        -o-transition: -o-transform .7s linear;
        /* Unprefixed transition and prefixed or unprefixed transform.
        transition-property: -webkit-transform -moz-transform -o-transform transform;
        transition-duration: .7s;
        transition-timing-function: linear;
    }

[Joseph Pecoraro]

(In reply to comment #3)
>         /* Unprefixed transition and prefixed or unprefixed transform.

Of course this comment should be ended on this line with */ =)

[Joseph Pecoraro]

(In reply to comment #3)
@Nick, actually doing the following should be just fine:

     #pass, #back, details, .animate {
         -webkit-transition: -webkit-transform .7s linear;
         -moz-transition: -moz-transform .7s linear;
         -o-transition: -o-transform .7s linear;
         transition: transform .7s linear
     }

If both unprefixed version aren't supported, then the browser should just fallback to the prefixed lines above the unprefixed line.

[Nick]

Confirm that CSS fix works, thanks for your help Joe.