SVG Icon grid at http://glyph.smarticons.co/ is broken in nightly

RESOLVED FIXED

Status

Tech Evangelism
Desktop
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: dholbert, Unassigned)

Tracking

({regression})

Trunk
regression

Firefox Tracking Flags

(firefox41 affected)

Details

(Whiteboard: [sitewait] , URL)

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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)
(Reporter)

Comment 1

2 years ago
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)
(Reporter)

Comment 2

2 years ago
(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 )

Comment 3

2 years ago
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=17fc891eb84a&tochange=be715c1edaeb

Triggered by Bug 923193

Seems TE bug
Blocks: 923193
(Reporter)

Comment 4

2 years ago
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.
Flags: needinfo?(jwatt)
Keywords: regressionwindow-wanted
(Reporter)

Comment 5

2 years ago
(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.)

Comment 6

2 years ago
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");

Comment 7

2 years ago
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.
(Reporter)

Comment 8

2 years ago
I filed https://github.com/frexy/glyph-iconset/issues/1 on this issue.
(Reporter)

Comment 9

2 years ago
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.)
Component: SVG → Desktop
Product: Core → Tech Evangelism
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.
Flags: needinfo?(jwatt)
(Reporter)

Comment 11

2 years ago
(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!)
(Reporter)

Comment 12

2 years ago
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.

Comment 13

2 years ago
Done.
Setting [sitewait] since it's been reported to them and it seems they have acknowledged the report.
Whiteboard: [sitewait]
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.