Page MenuHomePhabricator

CSSMin: Support @embed for external urls
Closed, DeclinedPublic

Description

I've added
#firstHeading {
/* @embed */
background-image: url(http://localhost/mw/skins/common/images/feed-icon.png);
}

to Special:MyPage/common.css (and to MediaWiki:Common.css), but the background image is not being converted to base 64 as it should.

I may be just misreading the docs[1] or doing something wrong, but maybe it is a bug?

[1] http://www.mediawiki.org/wiki/ResourceLoader/Features#Embedding


Version: unspecified
Severity: enhancement

Details

Reference
bz40832

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:04 AM
bzimport set Reference to bz40832.
bzimport added a subscriber: Unknown Object (MLST).

It only works for files stored on disk, not for URLs. This is because it needs to be able to invalidate cache when the file is changed, and there is a limit to the file size allowed in embeds.

One could open a feature request to support URLs in the future, but at this time this is not a bug and it is not related to user/site scripts (embedding files from a URI isn't supported from core modules either).

Of course for core modules all icons are on disk, as there is no reason to use them from a URL. And from user/site scripts there is no way to select a file from disk, because that can only be done from a relative path, and for a wiki page script, there is no relative path because it is a page, not a real css/js file.

I believe there is an open ticket to request support for referencing wiki files from wiki scripts, something like:

background-image: url([[File:Example.svg|22px]]);

background-image: url(mw-file://Example.svg/22px);

background-image: -mw-file(Example.svg, 22px);

But that's something else entirely.

(In reply to comment #1)

One could open a feature request to support URLs in the future,

So, let us make this bug into a request for that.

'It only works for files stored on disk...'

My gadgets often call static images in the following way:

background-image: url(/w/skins/vector/images/tab-break.png);

If embedding works only on relative paths, it should work on absolute paths as well. Relative paths always need to be expanded anyway, by either client or server. So it seems trivial to at least make absolute resources like the above embeddable. Correct me if I'm wrong though.

Erwin: Your URL is absolute on the URL scheme, but not on the filesystem. That path doesn't exist on the filesystem.

It may work if enabled (I highly doubt @embed even attempts to find the file on the local filesystem on either gadgets or skin and user CSS) but that would be tricky, since it should be relative to the current file, and those are wiki pages, not files.

We may assume they should be relative to the MediaWiki installation path, but such feature may be a security breach. Imagine this code:

#soemthing {

/* @embed */ background-image: url(LocalSettings.php);

}

Or whatever file that may contain sensitive information or passwords.

For that reason I think support for embedding local files on any resource that can be modified by a user (even sysops) is not feasible and shouldn't be supported at all.

I would recommend strongly against embedding arbitrary URLs, as that just sounds like trouble to deal with (DoS, cache invalidation, who knows what else :)

However being able to embed a file that's uploaded to the wiki? Might be useful for things like gadgets and site scripts -- that can also do handy things like:

  • abstract the low-level URL from the file (even if you don't embed)
  • guard against embedding overlarge files

Perhaps something specific to ResourceLoaderWikiModule...

Krinkle renamed this task from ResourceLoader: Add support for files from urls to @embed in CSSMin to CSSMin: Support @embed for external urls.Apr 28 2015, 6:46 PM
Krinkle closed this task as Declined.
Krinkle set Security to None.
Krinkle removed a subscriber: Unknown Object (MLST).