I think the best thing to do would be add the following simple code, the reason for this is that the code after the failed console.log will not be executed causing unexpected user experience that might just work fine otherwise.
if (!window.console) window.console = {};
if (!window.console.log) window.console.log = function () {};
Also checking browser stats today, IE9 is quite rare. IE8 is much more globally common mainly because Windows XP users cannot upgrade to any higher version of IE. And we do not even pretend to work on IE8 of course, we sort of work on IE9 in an âabsolute bare bones minimumâ kind of way.
I will try to track down where that console.log is coming from though.
Problem is there are ~150 instances of console.log, probably ~100 of those are in external dependencies and I canât tell which ones matter⌠looks like some of the dependencies set up custom handling for the console, e.g.
Maybe itâs better to look at it this way: is anything unusual (other than pushstate, which doesnât exist) broken in IE9?
Can you answer that question @DeanMarkTaylor ? That might be more useful to us than regurgitating a bunch of javascript error logs submitted by the client⌠I did download the IE9 vm which is 3.5 gb, but itâs hard to make time on MLK day with 3 kids at home, etc.
I canât talk for Discourse specifically, but this will affect IE8 and 9 - basically, console gets created the first time a user opens the developer console (ever, in the whole life of that browser) and exists for ever more.
Speaking from experience it is an extremely annoying problem to track down, and you will more than likely miss some other features that arenât working.
I have found that building a fake console (as in @codinghorror post) is the easiest way to deal with this.
Right now our Javascript linting is designed to raise errors on console.log and not push to tests-passed. however they can still sneak in sometimes in files that are not linted properly.
Also we still sneak in logs using the {{log}} helper in Ember, but I checked their implementation and it seems like it should work in IE9.
Filling it with an empty function like @DeanMarkTaylor suggested is a pretty good solution. I could make an initializer to do that and call it âie9-haxâ or something to make it easy to find later on.