Page MenuHomePhabricator

[Epic] SVG client side rendering
Open, LowPublic

Tokens
"Love" token, awarded by JoKalliauer."Like" token, awarded by ToBeFree."Like" token, awarded by Liuxinyu970226."Love" token, awarded by MichaelSchoenitzer."Heartbreak" token, awarded by sladen."Love" token, awarded by FoXFTW."Like" token, awarded by He7d3r."Like" token, awarded by fbstj."Love" token, awarded by Perhelion."Like" token, awarded by Ricordisamoa.
Assigned To
None
Authored By
bzimport, Oct 4 2005

Description

Please add an option to allow client side SVG rendering.

See Also: T10901: [DO NOT USE] SVG rasterisation and management on Wikimedia sites (tracking)

Details

Reference
bz3593

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
demon removed a subscriber: demon.Nov 28 2014, 2:27 AM

Here is another free JavaScript technique to do so (depending on client browser): http://voormedia.com/blog/2012/10/displaying-and-detecting-support-for-svg-images

I mean this would be a perfect solution for MediaWiki and an high quality boost! (because of the bad old libRSVG and very poor support [http://git.gnome.org/browse/librsvg/stats/?period=y&ofs=-1])

Change 182332 had a related patch set uploaded (by Ricordisamoa):
[WIP] enable native client-side rendering of SVG images

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

Patch-For-Review

Baba66 added a subscriber: Baba66.Dec 31 2014, 10:41 AM

Maybe it is better first to enable it as beta-feature in the preferences!?

As far as I can see this patch just adds a boolean whether to serve SVG or not. It does not take into account browser support, OS (desktop or mobile) and the size of the SVG (some SVG are several MB!)?

Maybe it is better first to enable it as beta-feature in the preferences!?

While it may work fairly well on private wikis, it surely won't make it into the WMF release as-is.
Anyway, adding a user preference sounds nice.

As far as I can see this patch just adds a boolean whether to serve SVG or not. It does not take into account browser support, OS (desktop or mobile) and the size of the SVG (some SVG are several MB!)?

Yes, that's why it's marked 'WIP'. It should support more configuration options and provide PNG fallbacks when possible.

fbstj added a comment.Jan 7 2015, 9:02 AM

@Ricordisamoa thank you for working my patch into a proper thing. I'm really glad there's some progress happening.

Menner added a subscriber: Menner.Jan 18 2015, 9:24 AM

I see unresolved security issues since SVG may contain JS script and references to external webpages. There must be some sort of filter for that kind of stuff otherwise it is a huge entry point for hackers.

I see unresolved security issues since SVG may contain JS script and references to external webpages. There must be some sort of filter for that kind of stuff otherwise it is a huge entry point for hackers.

We actually have a filter. Although I'm not confident its fully up to the task if filtering svgs suddenly became critical

Paladox added a subscriber: Paladox.Jun 6 2015, 2:33 PM

Common should add support for using .svg instead of .svg.png.

Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 16 2015, 9:03 PM
Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:16 PM
Restricted Application added a subscriber: Steinsplitter. · View Herald TranscriptSep 4 2015, 6:16 PM
Perhelion added a comment.EditedSep 29 2015, 12:00 PM

I have a last strong idea/suggestion (to the only hard contra argument bad SVG): How about setting up the Reviewer system (Wikipedia:Flagged revisions/Sighted versions) for SVG files!? As this system works very good in the German WP for articles.
So we could maybe add a new user group SVGreviewer (for native client rendering)!?

Edit: On Commons that would include the similar maintain templates: invalidSVG and badSVG

Such proposal is unrelated to this report. You can check whether there is interest for such a feature in the relevant talk pages, e.g. https://commons.wikimedia.org/wiki/Help:SVG , and then file a feature request separately.

Perhelion added a comment.EditedSep 29 2015, 8:28 PM

@Nemo_bis:
Sorry I really don't get your comment, I mean this fully related to this topic (and I see also no concrete relation to Help:SVG). Without any similar feature there will be never a client side rendering.
Maybe a size check is the minimum similar feature (what I meant).

What I mean with "bad SVG for clients" is this for example:

...
This does not attack the issue with overly large SVG files containing a lot of details, as far as I can see.
Please make sure that large SVGs are thumbnailed to PNG.

I have a last strong idea/suggestion (to the only hard contra argument bad SVG): How about setting up the Reviewer system (Wikipedia:Flagged revisions/Sighted versions) for SVG files!? As this system works very good in the German WP for articles.
So we could maybe add a new user group SVGreviewer (for native client rendering)!?

Edit: On Commons that would include the similar maintain templates: invalidSVG and badSVG

I don't want wiki users to be responsible for ensuring that svgs do not contain malicious js. Site security is not something that should be up to individual users.

We will not do this feature, unless we are confident that our internal filter is sufficient to prevent malicious code in svgs (An alternative might be to have svgs in an entirely different domain, and shown via in iframe sandbox)

Here a good example, as long as users do not show understanding for file-size, this would be one of the main counterpoints.
Commons:User talk:Rcsprinter123 #

Catrope removed a subscriber: Catrope.Nov 13 2015, 7:58 PM
Restricted Application added a project: Commons. · View Herald TranscriptNov 13 2015, 7:58 PM
zhuyifei1999 moved this task from Incoming to Backlog on the Commons board.Nov 14 2015, 11:23 AM
zhuyifei1999 added a subscriber: zhuyifei1999.
fbstj awarded a token.Dec 15 2015, 2:57 PM
fbstj removed a subscriber: fbstj.
Meno25 removed a subscriber: Meno25.Feb 22 2016, 7:14 PM
brion added a comment.May 4 2016, 4:52 PM

I don't want wiki users to be responsible for ensuring that svgs do not contain malicious js. Site security is not something that should be up to individual users.

We will not do this feature, unless we are confident that our internal filter is sufficient to prevent malicious code in svgs (An alternative might be to have svgs in an entirely different domain, and shown via in iframe sandbox)

SVGs are already filtered for scripting security at upload time, and in Wikimedia production they are already served from a separate domain. Further, SVGs in <img> elements are already sandboxed by browsers and cannot run scripts (though if you load the same file directly of course it'll happily run scripts).

Restricted Application added a subscriber: Poyekhali. · View Herald TranscriptMay 4 2016, 4:52 PM
brion renamed this task from SVG client side rendering to [Epic] SVG client side rendering.May 4 2016, 4:52 PM
brion removed a project: Patch-For-Review.
Danny_B added a subscriber: Danny_B.May 5 2016, 6:33 PM

Considering bunch of Brion's new tasks, how about converting this in fact Tracking-Neverending task either to subproject of Wikimedia-SVG-rendering or project of its own?

Change 182332 abandoned by Ricordisamoa:
[WIP] enable native client-side rendering of SVG images

Reason:
I've rebased the change just in case someone wants to revive it, but I'm abandoning it as it was nothing more than a proof of concept. Ongoing work by Brion at T134482

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

He7d3r added a subscriber: He7d3r.
sladen added a subscriber: sladen.
Dvorapa removed a subscriber: Dvorapa.Nov 28 2017, 11:07 AM
gpaumier removed a subscriber: gpaumier.Jul 18 2018, 6:02 PM
In T5593#78746, @cscott wrote:

Note that the 'lang' option won't work for client-side SVG rendering; see bug 58920.

That's T60920: lang support for SVG images using SystemLanguageAttribute ill-defined and not properly supported in browsers now; just quoting myself to link the bugs properly in phabricator.

Magol added a subscriber: Magol.Oct 6 2018, 9:30 AM
mxn added a subscriber: mxn.Nov 10 2018, 10:08 PM
Leksey added a subscriber: Leksey.Jan 5 2019, 10:02 PM