mozregression says: 5:30.21 INFO: Last good revision: 9d6ffc7a08b6b47056eefe1e652710a3849adbf7 (2016-01-06) 5:30.21 INFO: First bad revision: 1424cdfc075d1b7e277be914488ac73e20d1c982 (2016-01-08) 5:30.21 INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9d6ffc7a08b6b47056eefe1e652710a3849adbf7&tochange=1424cdfc075d1b7e277be914488ac73e20d1c982 In that range, looking for the word "filter", this commit from me looks potentially related: > Bug 1236506: Add support for "-webkit-filter" as an alias for CSS property "filter". r=heycam I'm not sure offhand how that would make a difference, because the site uses `filter` further down than the `-webkit-filter` alias, which means the `filter` line would win anyway: ``` .css-filter-enabled .post:hover .image, .css-filter-enabled .post.hovered .image, .css-filter-enabled .post:hover .video, .css-filter-enabled .post.hovered .video, .css-filter-enabled .post:hover .fotorama__img, .css-filter-enabled .post.hovered .fotorama__img { -webkit-filter: url(#blueify); -moz-filter: url(#blueify); -ms-filter: url(#blueify); -o-filter: url(#blueify); filter: url(#blueify) }``` ...though it could be that they do some feature-detection and sniff for e.g. "-webkit-filter" support (perhaps combined with UA sniffing) and do something silly if they detect it. The other thing I noticed is that this `#blueify` filter lives in a `svg` element at the bottom of the page, with ID `filters`, which is `display:none`. If I remove `display:none`, then it suddenly starts working correctly in current Firefox.
Bug 1596979 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
mozregression says: 5:30.21 INFO: Last good revision: 9d6ffc7a08b6b47056eefe1e652710a3849adbf7 (2016-01-06) 5:30.21 INFO: First bad revision: 1424cdfc075d1b7e277be914488ac73e20d1c982 (2016-01-08) 5:30.21 INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9d6ffc7a08b6b47056eefe1e652710a3849adbf7&tochange=1424cdfc075d1b7e277be914488ac73e20d1c982 In that range, looking for the word "filter", this commit from me looks potentially related: > Bug 1236506: Add support for "-webkit-filter" as an alias for CSS property "filter". r=heycam I'm not sure offhand how that would make a difference, because the site uses `filter` further down than the `-webkit-filter` alias, which means the `filter` line would win anyway: ```css .css-filter-enabled .post:hover .image, .css-filter-enabled .post.hovered .image, .css-filter-enabled .post:hover .video, .css-filter-enabled .post.hovered .video, .css-filter-enabled .post:hover .fotorama__img, .css-filter-enabled .post.hovered .fotorama__img { -webkit-filter: url(#blueify); -moz-filter: url(#blueify); -ms-filter: url(#blueify); -o-filter: url(#blueify); filter: url(#blueify) } ``` ...though it could be that they do some feature-detection and sniff for e.g. "-webkit-filter" support (perhaps combined with UA sniffing) and do something silly if they detect it. The other thing I noticed is that this `#blueify` filter lives in a `svg` element at the bottom of the page, with ID `filters`, which is `display:none`. If I remove `display:none`, then it suddenly starts working correctly in current Firefox.