[Bug] [Regression] JPEG compatibility now broken on Backend 4 as well as all others. Site incorrectly serves WEBPs named .jpg #25
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I am unsure if this issue affects only Nadeko Invidious or all Invidious instances.
Please escalate to Invidious if applicable.
As of now, Nadeko Invidious Backends 1, 2, 3, and 4 have all stopped supporting thumbnail image rendering correctly.
Due to Postel's Law (see Wikipedia), the issue is most or possibly only apparent on clients that do not support the WEBP picture format. While YouTube correct serves .webp images to supporting browsers and .jpg images to others, Nadeko Invidious backends have now stopped serving JPGs and only serve WEBPs. Worse, Nadeko/Invidious backends serve WEBP thumbnail files named .jpg. These will still render ok on very error-tolerant WEBP-supporting browsers which disregard the file extension and just render .jpg files that are disguised WEBPs like .webp files. However, the current regression breaks all thumbnail support on less fault-tolerant and older clients -- precisely the kind of clients whose users might be turning to Nadeko Invidious for performance reasons.
Previously, until a day or two ago, Nadeko Invidious was still mostly backwards-compatible with JPEG thumbnails -- in the same way that YouTube supports JPEGs for browsers/clients which request JPEGs, and maybe can't handle WEBP images. However, correct JPEG support was already broken on Backend 1 earlier, though Backend 4 and others kept supporting thumbnail pictures correctly until recently.
Steps to Reproduce
As an example, take the mqdefault thumbnail for the video with ID xeLlwvHJWr4. This is just an example -- any other ID/thumbnail should work the same:
YouTube correctly serves and renders this JPG to WEBP-incompatible clients:
https://img.youtube.com/vi/xeLlwvHJWr4/mqdefault.jpg
Invidious serves this image source link: src="/vi/xeLlwvHJWr4/mqdefault.jpg"
That link expands to: https://inv.nadeko.net/vi/xeLlwvHJWr4/mqdefault.jpg
However, the mqdefault.jpg file Nadeko/Invidious actually serves is not a JPG. It is a WEBP file. Again, Invidious used to correctly serve the .jpg as a JPG, but it now no longer does. If https://inv.nadeko.net/vi/xeLlwvHJWr4/mqdefault.jpg is accessed directly using e.g. a Firefox browser old enough to not support WEBPs, a dialogue box will open and say:
You have chosen to open:
mqdefault.jpg
which is: WebP image
Careful when troubleshooting this -- Chrome in particular tries to be "smart", hence if you access https://inv.nadeko.net/vi/xeLlwvHJWr4/mqdefault.jpg and go right-click save-as, Chrome will try to correct the file type--file extension mismatch and offer to save the mqdefault.jpg file as mqdefault.webp, a thumbnail which does not actually exist on the nadeko server. Chrome's overeager autocorrection can be really confusing here.
Oddly enough, https://i.ytimg.com/vi/xeLlwvHJWr4/maxresdefault.jpg seems to be a JPG all the way on YouTube. It's only on Nadeko/Invidious that https://inv.nadeko.net/vi/xeLlwvHJWr4/maxresdefault.jpg turns out to be a secret WEBP.
--
The following might be two separate issues, but I'm not sure if they deserve their own tickets here -- I would have emailed you about it if I had your email:
When trying to register for git.nadeko.net on older browsers, the mCaptcha (mcaptcha.nadeko.net) does not display. Registration can be completed using a less old Chromium browser instead, however see 2.
On completing registration, after email confirmation and typing in the password on the "Activate your account" page, the Nadeko git site displays an "Internal server error" page, which is off-putting. Apparently registration is still completed, and after that, it is possible to log in to the Nadeko git site, even using older browsers that don't support mCaptcha, see 1.
Thanks for your attention.
This is probably another separate issue, but:
This is how a bug report should look like. 10/10
I already fixed it so try again.
About the other bugs:
For this I can just set an image captcha instead.
I didn't really care because Forgejo needs JavaScript to work but mCaptcha is not only JS, it's WASM.
Also, which browser is the older browser you are referring too?
Thanks for the kind words, and please allow me to return the compliment: Yours is just about the best response to a bug report I can remember. The first time I even got to look back at this report, you had already fixed the issue, and I can confirm images presently appear to work again, at least on my machine. Much respect.
What I'm not sure of: Do you think this was only a Nadeko issue, or a broader Invidious issue? I dimly recall having encountered other Invidious instances with similar issues, but I'm not sure. Should a further bug report be filed with Invidious? If so, will you escalate or should I try and file something at https://github.com/iv-org/invidious/issues/new ?
When it comes to my use of very old browsers, I am in part proudly embracing retrocomputing and obstinately digging in my heels in defence of maximum backwards-compatibility out of principle, but equally so, I am partly embarrassed to admit exactly how old some of my browsers actually are. I am also partly paranoid of becoming uniquely identifiable by major browser version number alone, because who else still uses FF56.0? I don't actually know if this browser supports WASM. Is there a way to test this or a place I could look that up? I have looked at https://git.nadeko.net/user/sign_up again in a private/incognito tab -- and it looks like you've taken out mCaptcha entirely, I think? I have not tried to register another new account because I already have this one. I also don't know if I would see the Internal server error page again upon re-registering, or if I will see another JSON page upon clicking the Comment button below this box. (Maybe I will?) I suppose those are Forgejo issues? I'm not sure if that's your project also, or if it's worth escalating anything to some other place for that also. (Tbh, these things are not major concerns to me at this time.)
Again, the WEBP/JPEG thing that I was really worried about appears to be fixed. Does that mean you or I should close this issue? NB: I might be substantially slower to respond than you -- again, thanks for being so very much on the ball with everything. Much appreciated, and all the best! :-)
It was only an issue on my instance. I use an external program to proxy the images (thumbnails, profile pictures, channel pic, banners, etc) and by default it uses WEBP so I changed it back to JPEG.
Yeah hell no, it's not supported at all. https://caniuse.com/wasm
You can try using https://demo.mcaptcha.org/widget/?sitekey=pHy0AktWyOKuxZDzFfoaewncWecCHo23 if you want to do some tests. Most JS captchas (mCaptcha, Google Captcha, Cloudflare Captcha) use WASM so I doubt they are going to work on very very old browsers.
This is not highly important but I will try to reproduce it later.
Since the main issue is already resolved I will close this.
I hope I'm not doing anything wrong by still adding this comment in reply to a closed issue? This is just to share the following additional information, in case it might still be of interest and/or useful:
If I read https://caniuse.com/wasm correctly, it does seem to say WASM has been supported on FF since 52.0, so it should be supported on FF 56.0.
The mCaptcha demo however does not seem to work for me. I wonder if it makes sense and if there's a way to escalate that to mCaptcha? Knocking out a basic CAPTCHA service on older browsers cuts off a long tail of retro setups everywhere mCaptcha is used.
Thanks again.
Maybe not, I doubt the developer wants to support older browsers hence lowering the protections that mCaptcha offers.
I may add an alternative captcha option like the one I have in the registration page (git.nadeko.net) to support text captchas but that is not happening tomorrow or next week.