In the footer the arrow and the magnifying glass do not display properly.

Tested on firefox 57 (developer edition)
CC @LukyVj 馃檹
if it's a background image in svg, we need to replace # by %23, FF is the only browser which breaks on that.
EDIT: not the case, might however be related to the fact that we specify width _and_ viewbox
On it!
Okay so, the plan here ( and on every community project I tested ) is to replace all icons with our iconfont ( see: https://github.com/algolia/algolia-fonts )
For now, I cannot really take care of this, but I will as soon as I'm done with the grader redesign.
@Haroenv do you think you can fix that like you fixed the powered-by?
Be aware that this is a bug in Chrome and probably Safari when SVG2 is landing.
See the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1433360#c2 with spec reference.
To fix the issue it is necessary to put the width on the use element.
There's a pretty easy fix here (from the Mozilla bug report). In cases where you have something like this...
<svg width="22">
<use xlink:href="#search-icon">
...you should add an explicit width="100%" height="100%" on to that <use> element, like so:
<svg width="22">
<use xlink:href="#search-icon" width="100%" height="100%">
Otherwise, the SVG 2 spec says the browser has to copy the width attribute from the element that it's cloning, when generating the <use>-clone. (In this case, #search-icon has width=40, so we put that on the clone and that's sadly too wide to fit in the 22px-wide outer SVG container -- and that's why it overflows.)
Chrome follows the older SVG 1.1 spec here, which is to default to behaving as if width="100%" height="100%" had been specified, basically. So if you want the behavior that you're getting in Chrome, then you can just specify those attributes explicitly on the <use> element and you'll get that behavior in Firefox as well.
(Ah, it looks like perhaps you folks fixed this by instead removing the explicit width and height from the <symbol> element in https://github.com/algolia/instantsearch.js/pull/2675/commits/03834157620720e97e9856169d89d1ce2db158ea . That's good too and is another way of achieving the same end result, which is to avoid having an explicit pixel size on the <use>-produced clone.)
Thanks @dholbert and @karlcow Didn't about all that, thanks for sharing your knowledge 馃憤
looks like this was fixed in #2675
Most helpful comment
Thanks @dholbert and @karlcow Didn't about all that, thanks for sharing your knowledge 馃憤