STR: 1. Load http://glyph.smarticons.co/ 2. Look at grid. EXPECTED RESULTS: Meaningful icons. (e.g. #1 is an abacus, #2 and #3 are sliders, #6 is an airplane) ACTUAL RESULTS: Small, unrecognizable glyphs. I get EXPECTED RESULTS from chrome dev channel & Firefox release (version 38). I get ACTUAL RESULTS from Firefox Nightly 41.0a1 (2015-06-03)
Created attachment 8615104 [details] screenshot: firefox release on top, nightly on bottom. (ignore blurring artifacts) Here's a screenshot. (ignore the weird blurring artifacts; that's a quirk of my new system that affects screenshots & that I haven't worked out yet)
(some context: this icon set was only just released, and it's gotten some pickup on twitter in the last day or so. Blog post announcing it: http://blog.smarticons.co/post/120503514276/introduce-glyph-an-open-source-svg-icon-set )
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=17fc891eb84a&tochange=be715c1edaeb Triggered by Bug 923193 Seems TE bug
Thanks! I can confirm that I get EXPECTED REUSLTS if I disable that feature by flipping pref svg.transform-origin.enabled to 'false'. From a quick 'find-in-page' of their source (and the sprite-sheet http://glyph.smarticons.co/sprite.svg ), I don't see "transform-origin" anywhere, which makes me suspect this is indeed a Gecko bug rather than a TE issue. I might be missing something though.
(If there is something for the SmartIcons folks to fix here, though, it'd be worth reaching out on the sooner side, to minimize the number of sites that adopt the broken-in-Firefox version of this spritesheet.)
FYI, The following UA spoofing helps. user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36");
They also rely on our implementation of <use> not applying styles correctly. If and when we do that we'll need the same polyfill that the rest of the UAs require.
I filed https://github.com/frexy/glyph-iconset/issues/1 on this issue.
Reclassifying as Tech Evang. (I still haven't dug into the C++ changes on bug 923193 to be sure there isn't actually a regression here. Leaving needinfo=jwatt to sanity-check that if he gets a chance.)
Hmm, I don't see any use of transform-origin or of percentage values in http://glyph.smarticons.co/sprite.svg so it seems suspiciously like this could be a regression. I'll take this and dig into it.
(I noticed the same thing. Was wondering if Alice had noticed something that I didn't see, in comment 3. :) Thanks for taking a look!)
Robert, would you mind chiming in on the github issue (linked in comment 8) with your observations about <use>? Depending on what jwatt discovers, that may be the only (theoretical, future) TE issue here.
Setting [sitewait] since it's been reported to them and it seems they have acknowledged the report.