This has been considered before in other places as well. It is not about browser support. This is about performance, rendering correctness and security.
SVGs can be very large documents not intended for client-side rendering. Viewing the original is not the same as viewing a large thumbnail. Mediaviewer is meant to display large thumbnails, not originals.
- Rendering correctness:
Browsers vary widely in how they render SVGs. They may have varying levels of support for SVG features, have additional fonts installed etc. The rendering of SVGs on Commons very tightly depends and assumes a specific set of fonts, character sets, widths of glyphs in those fonts in relation to other aspects of the design. This should not be rendered client-side in a browser.
We currently render these SVGs only from upload.wikimedia.org, which is explicitly untrusted, and has stricter CSP rules set as well.
The MediaWiki software is responsible for safely deciding when an original can be used. The thumbnail API will use the original in limited cases, such as JPEGs, when the requested thumbnail size is larger than the original and the original file type is considered safe (such as JPEG). This logic does not belong in MultimediaViewer, and must not be bypassed. The MediaWiki thumbnail API will never serve the original SVG no matter which thumbnail size is requested, and it behaves that way for a reason.
Hm. This sounds like a misunderstanding to me. The removed code literally said isBrowserSupported, as well as "MuyltimediaViewer uses SVG icons extensively and is unusable without them." As far as I can tell there is no code that expects to get .svg files from Commons. The removed code was exclusively about the .svg icons that are part of the MultiMediaViewer codebase. Performance, rendering correctness, and security apply to these as well, but should be fine, because these files got individual review.