I'd like that we try to play with the quality as well, because here you'll probably not save much by resizing the same file with the same limit, and we might end up in an infinite loop.

So the algorithm could be that you first use a quality of say 75, and then decrease it if we still exceed the limit.
To save time, maybe it's possible to first compress with a quality of 100 or default quality (92) to the target dimensions, and if necessary we recompress that already compressed image using a quality 75 or 65 (so that we don't try to resize again using the big input file), and etc.

default quality in gecko is 92 (see https://mxr.mozilla.org/mozilla-central/source/image/encoders/jpeg/nsJPEGEncoder.cpp#81 and https://mxr.mozilla.org/mozilla-central/source/image/public/imgIEncoder.idl#55).

I just discovered that we don't seem to support the quality argument for toBlob yet and I've filed bug 891884 for this...