Page MenuHomePhabricator

CSSMin is not path-remapping for multiple 'url's
Closed, ResolvedPublic

Description

Autonym font loading causes hits to the [[Font/Autonym.ttf]] article. Incredible, but apparently true: http://stats.grok.se/en/latest30/Font/Autonym.ttf (unless the stats are wrong).

I have absolutely no idea what could be causing this. Maybe the stats are completely bonkers, or ULS does something very, very wrong. Or maybe it's a server misconfiguration issue. Either way something's incredibly broken.

(Not sure what product/component would be most appropriate, going with ULS for now.)


Version: 1.23.0
Severity: major

Details

Reference
bz56514

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:32 AM
bzimport set Reference to bz56514.

I did some search in the CSS

The fontface is defined in UniversalLanguageSelector/lib/jquery.uls/css/jquery.uls.css as

@font-face {
font-family: 'Autonym';
src: url('font/Autonym.eot');
src: local('Autonym'),

		url('font/Autonym.woff') format('woff'),		
		url('font/Autonym.ttf') format('truetype');

font-style: normal;
}

And the RL outputs the css as:

@font-face{
font-family:'Autonym';
src:url(//bits.wikimedia.org/static-1.23wmf1/extensions/UniversalLanguageSelector/lib/jquery.uls/css/font/Autonym.eot?2013-10-24T17:33:20Z);
src:local('Autonym'),

		url(//bits.wikimedia.org/static-1.23wmf1/extensions/UniversalLanguageSelector/lib/jquery.uls/css/font/Autonym.woff?2013-10-24T17:33:20Z) format('woff'),
		url('font/Autonym.ttf') format('truetype');

font-style: normal;
}

For the truetype part, see the URL is wrong. For old browsers without woff support, the ttf will be tried and I assume that cause the hit.

As a side note, this css was changed in master yesterday (see https://gerrit.wikimedia.org/r/#/c/93034/ and https://gerrit.wikimedia.org/r/#/c/93035/) So the fonts will be served using jquery.webfonts which takes care of URLs to font repo.

Hmm. Now that you pointed the issue out, I realized that the CSS preprocessor in core MediaWiki only supports processing one url() per CSS rule. That should probably be fixed.

Since the ULS master changed how this css is defined, the issue remaining is with the CSS preprocessor. So changing the component accordingly.

To be able to assess priority: What are the current consequences for ULS and font loading?

As the impact is major, should any work-arounds be considered?

(In reply to comment #5)

To be able to assess priority: What are the current consequences for ULS and
font loading?

Autonym font does not work in some browsers. A few million unnecessary requests per day are sent to Wikimedia servers.

(In reply to comment #5)

As the impact is major, should any work-arounds be considered?

I think Santhosh has already applied a workaround?

(In reply to comment #2)

As a side note, this css was changed in master yesterday (see
https://gerrit.wikimedia.org/r/#/c/93034/ and
https://gerrit.wikimedia.org/r/#/c/93035/) So the fonts will be served using
jquery.webfonts which takes care of URLs to font repo.

Or was this something else? If it fixes anything, it doesn't seem to be deployed yet (looking at the stats).

Has anything been done about this from the ULS side? The stats linked in
comment 0 are still showing 2,500,000 hits daily to that false article, and
this only includes the English Wikipedia.

Change 94511 had a related patch set uploaded by Bartosz Dziewoński:
Rewrite CSSMin::remap to support multiple url() values in one rule

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

(According to the stats, the stupid requests stopped on 2013-11-15.)

Change 94511 merged by jenkins-bot:
Rewrite CSSMin::remap to support multiple url() values in one rule

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

And the root cause in core should be fixed too. Rejoice.