I also wonder if we're trying to do much. It's already evident we don't have enough engineering resource to move some of these tickets. If the goal is to serve SVG files to be rendered in the client, then we should probably stick to SVG 1 and if there are weird text issues, then it is incumbent on the uploader to fix - use a common font, convert text to shapes, etc. I'm just an punter not an employee, so maybe I'm wrong, but it seems to me that the overall scope is ultimately to provide vector diagrams to illustrate an encyplopædia. Maybe we don't need to get too fancy :) It sure would be nice to have SVG music snippets T49578 for example, some time this decade.

In T40010#10259652, @RazrFalcon wrote:

but resvg's loss of Yevhenii Reizner, who had been doing about 9/10 of the work from the beginning, is a serious threat to its future

Funnily enough, when I've started working on resvg around 2017, librsvg was dead/abandoned for more than a decade, which was one of the reasons behind resvg creation.
And like a year later, 2018ish, librsvg authors started a rewrite to Rust, which revitalized the library.

but resvg's loss of Yevhenii Reizner, who had been doing about 9/10 of the work from the beginning, is a serious threat to its future

I went ahead and proceeded to reframe this as a more specific request. I must clarify this does not mean I oppose marking this as a declined request. Or even as a processed request, since if this is an RFC as the title claims, this has already managed to gather its fair share of comments.

In T40010#425867, @Aklapper wrote:

What are the exact criteria to evaluate against, in order to get this ticket fixed? Currently this sounds unfixable due to vagueness.

In T40010#10252612, @Chealer wrote:

I note that some of the problems (file size and translations) with Native SVG rendering are already 'recognized' by:

• https://www.mediawiki.org/wiki/Manual:$wgSVGNativeRendering
• https://www.mediawiki.org/wiki/Manual:$wgSVGNativeRenderingSizeLimit

which would keep some of them on png by thumbor

Say the wiki page selects either the SVG or PNG rendering based on size. Say it is a small SVG file and SVG is selected. Now somebody comes along and uploads a 20 MB SVG images on top of the original, small, SVG. That would mean all the pages that reference that SVG file need to be rebuilt even though the aspect ratio did not change. Alternatively, the fetch of the overweight SVG should be turned into a PNG fetch. Maybe page rebuilds are not expensive, but some SVG files are used on a lot of pages.

In T40010#10252579, @AntiCompositeNumber wrote:

The qps codfw k8s and qps eqiad k8s graphs contain queries per second data for the current primary and secondary datacenter, respectively. Thumbor doesn't unconditionally echo requests from the primary to the secondary datacenter anymore, so the primary datacenter has a higher load. The CPU time for >75% of requests is recorded in the Processing CPU time graphs.
The numbers have all gone slightly up since 2020.

In T40010#10252569, @Bawolff wrote:

Re glrx:

I'm not an expert, but I think that change would be localized to Thumbor. If Thumbor is asked to rasterize an SVG file, it can notice the file is small and then serve it directly. If Thumbor sets the MIME type, then I think the img element will display it properly. But it also butchers the current semantics. A URL that formerly always gave a PNG file now might give an SVG file. Some OCR code I use will not take SVG but will take PNG; I use something like {{filepath:foo.svg|800}} to get a PNG. Maybe add something to the URL that requires a PNG or obey HTTP requests that ask only for a PNG MIME type.

While this is an option, i actually think its better to not have thumbor involved at all. I think it would be better to just make files with systemLanguage attributes always be rasterized (at least in the beginning). For other files i think we should treat it similar to jpgs, where sometimes we thumbnail and sometimes we send the original asset.

In T40010#10252569, @Bawolff wrote:

While this is an option, i actually think its better to not have thumbor involved at all. I think it would be better to just make files with systemLanguage attributes always be rasterized (at least in the beginning). For other files i think we should treat it similar to jpgs, where sometimes we thumbnail and sometimes we send the original asset.

Re glrx:

I'm not an expert, but I think that change would be localized to Thumbor. If Thumbor is asked to rasterize an SVG file, it can notice the file is small and then serve it directly. If Thumbor sets the MIME type, then I think the img element will display it properly. But it also butchers the current semantics. A URL that formerly always gave a PNG file now might give an SVG file. Some OCR code I use will not take SVG but will take PNG; I use something like {{filepath:foo.svg|800}} to get a PNG. Maybe add something to the URL that requires a PNG or obey HTTP requests that ask only for a PNG MIME type.

In T40010#6635039, @AntiCompositeNumber wrote:

According to Grafana, eqiad and codfw each get an average of 0.8 queries for new SVGs per second, with spikes up to 4 qps. More than 75% of those requests are handled using 575ms of CPU time on average. For context, there are 8.4 requests per second to eqiad and codfw for filetypes handled by imagemagick, including SVGs, which use 2-4s of CPU time.

In T40010#10251993, @Bawolff wrote:

If you are effectively saying that an SVG rasterizer yields better results on files which contain JavaScript than client-side rendering of the same file via <img>, please highlight that significant concern in T5593.

No, it would be mostly the same. Javascript is disabled in both contexts.

There are many issues with WMF's support of SVG.

If you are effectively saying that an SVG rasterizer yields better results on files which contain JavaScript than client-side rendering of the same file via <img>, please highlight that significant concern in T5593.

In T40010#10251565, @Bawolff wrote:

there was no robust and up-to-date FLOSS SVG sanitiser that could ensure that the SVGs were safe to display directly in the browser.

DOMPurify exists now and meets that criteria imho. However that is actually besides the point since svg in <img> tags do not execute javascript or external resources so is safe (embedding in an iframe/object is more risky, but probably not any more than the status quo and i dont think that is wanted anyways. The only really risky thing here would be to directly embed the svg tags in the html page, which i dont think anyone is suggesting). […]

there was no robust and up-to-date FLOSS SVG sanitiser that could ensure that the SVGs were safe to display directly in the browser.

In T40010#6639738, @Gilles wrote:

My recollection of why we don't serve user-submitted SVGs directly as thumbnails is that the last time this was looked at there was no robust and up-to-date FLOSS SVG sanitiser that could ensure that the SVGs were safe to display directly in the browser.

XML is notoriously hard to sanitise and there are new tricks invented regularly to bypass sanitisation. Essentially, we don't want to deal with the possibility of a badly intentioned actor being able to inject a tracking URL inside an SVG that would let them collect IP addresses of anyone viewing that image in an article, run some arbitrary javascript, or worse, being able to leverage a browser security flaw in SVG parsing.

Furthermore, we would still need to have fallbacks for browsers that either don't render SVG natively or do a terrible job at it.

In T40010#9653241, @Tercer wrote:

In a recent discussion in WikiProject Mathematics yet another rendering bug was encountered. Several users expressed the sentiment that SVG support in MediaWiki will never get fixed, and it is better to give up on them altogether and revert to PNGs. This is specially frustrating because the browsers can render the SVG correctly, but MediaWiki insists on passing it through librsvg and serving the resulting garbage instead.

@SD0001: Removing task assignee as this open task has been assigned for more than two years - see the email sent to all task assignees on 2024-04-15.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

@hoo Have you find time yet to process the new run completely? For others: I've asked during the Hackathon for another run as the data is more than two years old at this point and there is no sign of progress on the other task.

Change #1029626 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Change use of AtEase to at operator

https://gerrit.wikimedia.org/r/1029626

Change #1029626 had a related patch set uploaded (by Dreamy Jazz; author: 沈澄心):

[mediawiki/extensions/CheckUser@master] Change use of AtEase to at operator

https://gerrit.wikimedia.org/r/1029626

The proposed patch on Gerrit addresses precisely these problem - it introduces feature parity between gadgets and user scripts ("user gadgets"). All ResourceLoader features available to gadgets like loading dependencies, allowing multiple source pages, specifying peers for FOUC-free CSS loading, CommonJS module support, and conditional loading (based on namespaces, content models, skins, etc), would become available to 'user gadgets'.

The big problem I have with user scripts is loading dependencies and the incompatibility between gadgets and user scripts more generally.

Mathoid stopped serving PNG images for quite a while, and there were no complains, even though the SVG images from mathoid are quite special. Thus, we have one more data point that the browsers svg support is quite good.

In a recent discussion in WikiProject Mathematics yet another rendering bug was encountered. Several users expressed the sentiment that SVG support in MediaWiki will never get fixed, and it is better to give up on them altogether and revert to PNGs. This is specially frustrating because the browsers can render the SVG correctly, but MediaWiki insists on passing it through librsvg and serving the resulting garbage instead.

I want to note that not only this would be a helpful feature; the current user script architecture is, in fact, broken. It has been tacitly assumed since old times that user scripts are all enduser scripts and not modules to be reused by other scripts. But there is benefit to them being reused, and some indeed are, like libraries or utilities like this one I just wrote. They can be made into gadgets, but that would clutter the definitions, affect the overhead for regular users, and require a tedious wiki-bureaucratic process.

I'm tentatively removing MediaWiki-extensions-WikibaseClient here, because this is not actually about changing functionality on the client, but rather bringing something that works on the client also to the repository. Or did I get something wrong?