Port to WebExtensions

[ssokolow]

Mozilla will be dropping support for XUL extensions in Firefox 57, so this needs to be ported to the WebExtensions APIs before then if you want to keep it working. (And I'd really appreciate if that were the case)

If it can't be accomplished using WebExtensions APIs, you need to get onto Bugzilla A.S.A.P. to start a discussion on how to extend the APIs.

[simonlindholm]

... yeah. :( I hope to have time to do this during the summer. It requires pretty much a complete rewrite and getting API's for GIF manipulation into Firefox.

[ssokolow]

According to a discussion I had in #firefox, the shut-off is tied to the version number, so you only have until August 7th if you want to avoid disruption for users on the Aurora/DeveloperEdition channel. (another 6 weeks sooner for nightlies if their deadlines don't slip)

That's why I said A.S.A.P. about getting on Bugzilla. You need to get them designing and writing that API pronto.

EDIT: And please mention the bug here when you do open it, so I can follow the discussion.

[simonlindholm]

Thanks for the information about timing. I wonder when in the Nightly cycle it will land... Still, seems like I should have time in June and July if not before.

My (naive?) hope is that the API is small enough that I can just design and land it myself, without a very long discussion phase. (And FWIW if for whatever reason I don't manage to get APIs accepted into Firefox, I'll make them available as a webextension experiment so I can continue using the extension myself.)

[ssokolow]

Assuming no slipped deadlines, it'll land in Nightly on June 12th.

(I've been doing some serious research into this whole "XUL is going away" thing.)

[simonlindholm]

https://bugzilla.mozilla.org/show_bug.cgi?id=1378939 (and note also https://bugzilla.mozilla.org/show_bug.cgi?id=1364972 )

[ssokolow]

Thanks. I'm now following both of those.

[suy]

Hi. I see that https://bugzilla.mozilla.org/show_bug.cgi?id=1364972 is resolved, and some new API is added for FF 57. This doesn't seem as complete as fully controlling everything, but, can a pause/play button be implemented with that?

[simonlindholm]

Kind of - I suspect changing the setting only affects future page loads though. I'm currently experimenting with whether it's possible to exploit Firefox bugs/quirks to get the behavior I want. (In particular, image animation state is shared between images with the same source even across frames, and window.stop() stops image animation along with its other effects.)

[simonlindholm]

I rather missed the deadline here, but, anyway. Here's a possible plan for a port:

• Hook all web requests of type image and maybe main_frame (for image documents). (Will need some benchmarking to see what the perf implications of this are.)
• Check for each response that appears whether it has content-type: image/gif, and if so whether it is an animated GIF (APNG's will have to come at a later state; GIFV's I already have heuristic detection code for). Record each anim-gif-URL in a set, with LRU cache eviction or something.
• For each hovered image, and on load/loadstart events, check whether the URL is in the set. If so, mark it as animated and show control buttons and stuff.
• Using the API in https://bugzilla.mozilla.org/show_bug.cgi?id=1364972 we know the animation state of each frame -- namely, the global state at the time the frame loaded. Use this to figure out whether each individual image is animated. (This breaks down in obscure cases, but hey.)
• To pause an image, set the global animation state to "not animating", add a hidden iframe to the page, then set it back to "animating". This way the added frame has animations disabled. (While, assuming no race conditions, no other frames do.) Then do iframe.contentDocument.body.appendChild(image.cloneNode()). The added image clone will a) be served from the image cache, not incurring any web requests, b) be paused, because it's in a frame with animations disabled, and, somewhat subtly, c) also cause the original image to pause, since animations are keyed by URL. Then remove the image clone after it has had time to paint.
• To unpause an image, same thing.
• To reset an image's animation, set image.src = image.src. The HTML spec guarantees this to work without networky side-effects.
• For Ctrl+M, iterate over all images and pause/unpause them, and then maybe do something with load events to affect later loaded images...
• (Bonus!) Maybe add an option for stopping GIF network loads after the first frame, now that I'm hooking network requests and have a GIF parser lying around. Might break Connection: keep-alive and actually be bad for performance if I do it naively, though, and it will need some GIF parser surgery.

Hopefully I'll have time for all this at some point... In the mean time, the addon continues to work on Nightly, about:config's image.animation_mode = none still works, and with image.animation_mode = normal https://addons.mozilla.org/en-US/firefox/addon/superstop/ might be an alternative.

[rredford]

Hope you find a way. :) I miss this plugin so hard.

[mahpooya]

Looking forward to it! Thanks in advance.

[Mcinwwl]

Sorry for filling your comments... Just wanted to let you know that more people are awaiting WebExt version. Good luck.

[simonlindholm]

Thanks for the encouragement, all. I have some work-in-progress on the web-ext branch; current status is that it's buggy. Hopefully it's fixable, if not I guess I could do something more like https://github.com/buzzfeed/libgif-js or https://github.com/adamfur/GifJam. Still haven't tested performance.

[SuperSentient]

I noticed a bug with Firefox 57, it doesn't want to play animated gifs and I tried removing Toggle Animated Gifs (even though its still a legacy add-on) and it didn't help. My guess is that something got corrupted in Firefox when updating to version 57. Also good luck with updating TAG to a Web Extension.

[simonlindholm]

I suspect that's because the addon sets the image.animation_mode pref in about:config to none, and doesn't revert it on uninstall because Firefox 57 doesn't run uninstall code for legacy addons. You should be able to fix it by going to about:config and setting image.animation_mode to normal. Sorry for the inconvenience.

[SuperSentient]

@simonlindholm Thanks, But I already got some help last night from the Mozilla forums about this.:)

[danbruegge]

@simonlindholm hi, what is the status of the port? Do you need help?

[simonlindholm]

Thanks for asking. Life caught up with me, and I haven't had any time to look at this for the last two months... If you're interested in helping out, there's some work in progress in the 'web-ext' branch, and I could try giving some detail on how the code works. Status is that most of the big comment above is implemented, and sometimes it even works. However, it's buggy in a few ways:

• it doesn't follow redirects correctly (not hard to fix, just needs a bunch of code)
• it's somewhat broken with <imageset>s, which wikipedia uses
• generally, sometimes images just decide to revert to their original animation mode for no discernible reason. This might be because I was testing with <imageset>s, but either way it's worrying
• there are some issues with resetting images after they've changed animation mode
• hovering an image adds a funky-looking iframe to the page to aid with debugging, which would need to be marked invisible before the addon is suitable for daily use

So the way I'd continue this if I had time (likely won't for the next 1-2 months either) would be to first fix the redirect thing (to avoid false positives when testing), and do further testing of how stable the method is. Depending on that, either tweak things like resetting to work reliably and then ship an update, or re-think the approach and either implement my own custom GIF rendering or look into standization.

[danbruegge]

Thanks for the response. I'll check it out after my vacation. :)

[danyright]

Hey guys! Any news regarding the port? I don't have much time to help you code, but I could help you test if you need some testers. Thanks for your work

[simonlindholm]

Not much has happened since the last update. I may start to get time for this addon soon, though.

[Mcinwwl]

Hey, any chances project will move on any time soon? You have a bunch of fans, and your plugin has no replacement for Firefox 53 onwards.

[ghost]

On a related note, is anyone aware of an alternative with feature-parity? I don't want to disable GIF and HTML video autoplay entirely, only be default and play the files at will.

[ghost]

Even only implementing GIF-support would be very helpful, I occasionally come across older forums where every post seems to have animated GIFs (avatars, signatures, the message content). As far as I've understood implementing support for HTML video is delaying development.

[sergeevabc]

@simonlindholm, godspeed from still snow-covered Moscow.

[rredford]

Curious on what is current status on port. :)

[danbruegge]

Hej. Life got in the way. I had an idea of making a small gif only extension which only stops/starts a gif-image. But didn't found the time.

[mahpooya]

@simonlindholm Have you some required API missing, to continue developing this lovely addon? Do you defined missing APIs in bugzilla.mozilla.org? If you have, i will be glad to support it by adding my vote in them.

[alexolog]

Really missing this add-on. Willing to donate if it helps.

[alexolog]

Can the suggestions in the following work? https://stackoverflow.com/questions/3688460/stopping-gif-animation-programmatically/4276742 https://stackoverflow.com/questions/3062229/animated-gif-in-html5-canvas/6017468#6017468 https://github.com/ctrl-freaks/freezeframe.js