1224702 - [ruleview] Animated GIFs/APNGs on page start their animation from the beginning when I hover background-image url of those images to see image preview

Status: NEW

(DevTools :: Inspector: Rules, defect, P3)

Description

[arni2033]

Attachment: testcase 1 - Animated GIFs and APNGs on page start their animation from the beginning.html

STR:   (Win7_64, Nightly 45, 32bit, ID 20151113030248, new profile)
1. A) Open the following "data:" url or click url in the form above
>   data:text/html,<div style="background:url(chrome://browser/skin/tabbrowser/[e-mail]); height:100px; width:100px;"><img src="chrome://browser/skin/tabbrowser/[e-mail]" style="border:4px solid violet; background:gray;">
1. B) Open attached "testcase 1"   (unreliable, because those images may be deleted from imgur)
2.    Open devtools -> Inspector, select <div> element, open "ruleview" tab in sidebar
3.    Hover over the background-image url in ruleview

Result:
 All instances of same image on the page  start animation from the very beginning

Expectations:
 Observing preview in ruleview shouldn't affect animated images on the page, just like
 observing preview in inspector (e.g. 'src's of <img> elements) doesnt affect animated images

Note:
 Lack of animation in tooltips themselves is bug 1202178

Comment 1

[Patrick Brosset <:pbro>]

The inspector retrieves the image as a data-uri from the inspector actor.
See the imageToImageData function in https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/inspector.js
The process through which it does this seem to cause animated images to restart on the content page.

I came up with a reduced test case here: http://jsbin.com/goqixisohe/edit?html,css,js,output
The simple fact of creating a new Image object with the same url causes the animation to restart.

Comment 2

[Patrick Brosset <:pbro>]

Boris, please see the jsbin test case in comment 1, clicking on the button causes the animated image to restart at frame 0 in firefox apparently. Is this a bug? Is there a way to avoid it from content?

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Is this a bug?

No, it's by-design behavior; sites depend on it.  See bug 594771.  Actually a bit annoying to implement, too.  ;)

> Is there a way to avoid it from content?

From "content" in the sense of web content, or in the sense of the content process?

We could certainly add a [ChromeOnly] API to suppress this behavior, which would be visible in the content process, but only to system-privileged code.

Comment 4

[Patrick Brosset <:pbro>]

Thanks Boris.
By content I meant web content, but your proposal about the ChromeOnly API to do this sounds good.
I guess from web content, the only option would be to create the new image in a separate window. This behavior seems to be only occurring for images in the same window.

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK.  Do you want to take a shot at adding the API?  I can do it if you'd rather.

Comment 6

[Patrick Brosset <:pbro>]

(In reply to Boris Zbarsky [:bz] from comment #5)
> OK.  Do you want to take a shot at adding the API?  I can do it if you'd
> rather.
I feel bad saying this, because we need more platform hackers in the devtools team, but I really really don't have the time to work on this now. So, yes, please, if you can do this, that'd be awesome!

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: DOM bits. Add a way to control whether an nsImageLoadingContent is allowed to reset animations on load

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8688532 [details] [diff] [review]
DOM bits.  Add a way to control whether an nsImageLoadingContent is allowed to reset animations on load

uh, bug 594771 is sad.

Comment 9

[arni2033]

I just checked one more thing about GIFs in devtools... And Netmonitor handles this OK actually.
It creates new <image> with [src="data:image/gif,base64, ... ].
> screenshot:   http://ssmaker.ru/5f91694d.png

Comment 10

[Patrick Brosset <:pbro>]

Triaging (filter on CLIMBING SHOES).