SVG Icon grid at is broken in nightly



Tech Evangelism
2 years ago
a year ago


(Reporter: dholbert, Unassigned)




Firefox Tracking Flags

(firefox41 affected)


(Whiteboard: [sitewait] , URL)


(1 attachment)



2 years ago
 1. Load
 2. Look at grid.

Meaningful icons. (e.g. #1 is an abacus, #2 and #3 are sliders, #6 is an airplane)

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)

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)

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: )

Comment 3

2 years ago

Triggered by Bug 923193

Seems TE bug
Blocks: 923193

Comment 4

2 years ago

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 ), 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

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.

Comment 8

2 years ago
I filed on this issue.

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 so it seems suspiciously like this could be a regression. I'll take this and dig into it.
Flags: needinfo?(jwatt)

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!)

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
Setting [sitewait] since it's been reported to them and it seems they have acknowledged the report.
Whiteboard: [sitewait]
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.