User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36

Steps to reproduce:

URL: https://jsfiddle.net/bv14up7a/

canvas.toDataURL("image/webp") should produce webp image but at present, it falls back to png.

Actual results:

It falls back to png and gives data:image/png;base64

Expected results:

It should provide webp data:image/webp;base64

Hi @Jai Gupta, I've tested the issue and here are the results:
[Platforms affected]: Mac OS X, Ubuntu 18.04, Windows 10
[Environment, FF]: nightly 69.0a1, beta0b11, release 67.0.3
Safari 12.1 (13607.1.40.1.5)
on all cases the issue can be reproduced. Additionally, on other browser such as Chrome, the issue won't occur.
Further, I will set a component to it, if isn't the right one please fell free to change it.
This issue could be duplicate to 696573.
Thanks.

I'd like to support this request: https://bugzilla.mozilla.org/show_bug.cgi?id=1505383

Is there any progress on this? I have no idea how difficult it is to implement a WebP encoder, but I know that this is a serious shortcoming in Firefox for me. Any CMS that allows canvas based image manipulation has either to drop WebP support or restrict its use to Chromium based browsers. That's really a pity.

So because I am crazy I dug into the source to trace down the code path of toDataUrl.
Turns out it ends up here: https://github.com/mozilla/gecko-dev/blob/d36cf98aa85f24ceefd07521b3d16b9edd2abcb7/dom/base/ImageEncoder.cpp#L429

As you can see, FF will ALWAYS fall back to png EVEN IF it finds a suitable encoder

  if (!encoder && aType != u"image/png"_ns) {
    // Unable to create an encoder instance of the specified type. Falling back
    // to PNG.
    aType.AssignLiteral("image/png");
    nsCString PNGEncoderCID("@mozilla.org/image/encoder;2?type=image/png");
    encoder = do_CreateInstance(PNGEncoderCID.get());
  }

Funny enough, there IS a webp encoder present which could be used: https://github.com/mozilla/gecko-dev/blob/d36cf98aa85f24ceefd07521b3d16b9edd2abcb7/gfx/skia/skia/src/images/SkWebpEncoder.cpp

So can please someone changes the above lines so that it will accept webp?

Consequently this will also fix the toBlob function as well and therefore tick 2 boxes at once (and fix every piece of code that uses the ImageEncoder)

(In reply to ulima.ums from comment #4)

So because I am crazy I dug into the source to trace down the code path of toDataUrl.
Turns out it ends up here: https://github.com/mozilla/gecko-dev/blob/d36cf98aa85f24ceefd07521b3d16b9edd2abcb7/dom/base/ImageEncoder.cpp#L429

As you can see, FF will ALWAYS fall back to png EVEN IF it finds a suitable encoder

  if (!encoder && aType != u"image/png"_ns) {
    // Unable to create an encoder instance of the specified type. Falling back
    // to PNG.
    aType.AssignLiteral("image/png");
    nsCString PNGEncoderCID("@mozilla.org/image/encoder;2?type=image/png");
    encoder = do_CreateInstance(PNGEncoderCID.get());
  }

Funny enough, there IS a webp encoder present which could be used: https://github.com/mozilla/gecko-dev/blob/d36cf98aa85f24ceefd07521b3d16b9edd2abcb7/gfx/skia/skia/src/images/SkWebpEncoder.cpp

So can please someone changes the above lines so that it will accept webp?

Consequently this will also fix the toBlob function as well and therefore tick 2 boxes at once (and fix every piece of code that uses the ImageEncoder)

Ok Obvisouly I missread the code. I misstook thd && as ||.
It is still strange that no encoder is found because there is a webp encoder after all

This issue was partly resolved in Firefox 96, firefox 96 can only generate a webp dataurl with a fixed quality parameter. firefox 98 adds the quality parameter

Would it be possible to add support also for the "lossless" mode?
Compared to PNG (also lossless) it has 26% lower size.
Maybe it could be used "automatically" when quality is set to 1.0?

I just verified and this is already tackled. From Firefox version 105 onwards a quality of 1.0 will trigger the lossless variant of webp.

What a great news! Thank you for the info!
I was testing it on my ESR 102 and was sad it didn't work. Can't wait to ESR 115 :)