Page MenuHomePhabricator

[Epic] SVG client side rendering
Open, LowPublic

Tokens
"Like" token, awarded by Habitator_terrae."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 Gerrit Patches:

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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
Raymond added a subscriber: Raymond.Jun 2 2019, 5:42 PM

If you're intersted in see SVGs here is a script for you.

JoKalliauer closed this task as Resolved.Jun 9 2019, 7:49 AM
JoKalliauer claimed this task.

If you're intersted in see SVGs here is a script for you.

Thanks to @Habitator_terrae : there is now an option to allow client side SVG rendering:

Installation

Add following code to https://meta.wikimedia.org/wiki/Special:MyPage/global.js:

//[[:de:Benutzer:Habitator terrae/svgEinbinden]]
mw.loader.load('https://de.wikipedia.org/w/index.php?title=Benutzer:Habitator terrae/svgEinbinden.js&action=raw&ctype=text/javascript');

Finish!

Wasn't this bug about native client-side SVG rendering, without relying on third-party scripts?

@AfroThundr3007730 : The description is "Please add an option to allow client side SVG rendering.", therfore in my opinion this request/task is resolved, but I would agree there should be another new phabricator-Task about "Native client-side SVG rendering, without relying on third-party scripts".

I believe that's what this bug is already doing, judging by the related tasks list, comments, and commits. Changing the title might be more apt than closing (something like "Support native client-side SVG rendering"). Also when considering that its related subtasks are still open, it doesn't make much sense to close at this point.

@AfroThundr3007730 : According to https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Archive/Option_to_embed_SVGs_as_SVGs supporting native client-side SVG rendering seems to be impossible/stalled within the next years, not even for specific SVGs T208578 .
Anyway if someone whats to render it on client-side (f.e. animated SVGs) it is possible T5593#5234639 .

That's why this is an "Epic" bug (and should track such blocking issues)... nobody said it would be easy (if at all possible) to implement.

Custom user scripts can not be quoted as a "solution" here, as the issue is obviously unfixed in the MediaWiki software itself.

In that case, since this is a long-running epic -- one who's main task has not yet been resolved -- I have reopened it, and also added the other task for tracking.