[Webkit-unassigned] [Bug 20141] Cannot call pointer to function console.log

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=20141





--- Comment #26 from Victor Costan <costan at gmail.com>  2013-04-12 10:43:57 PST ---
@Glenn: The use case is exploring or debugging APIs. For example, if I want to see how DOM level 3 IME input events work, I can enter something along the lines of "document.querySelector('#id').oncompositionupdate = console.log" in the Web Inspector and start interacting with the field.

An example of using asynchronous APIs is reading a file from someone's Dropbox using my dropbox.js library. The easiest way to see how that works is to type the line below in the Web Inspector.

client.readFile("/path/to/file", console.log)

Another example is learning / debugging jQuery's XHR behavior.

jQuery.ajax({url: "/path/to/json", dataType: "json", success: console.info, error: console.warn)


@Erik: I would hope that the sites with the most traffic have a release process that ensures they wouldn't break in WebKit browsers, and I would assume that at least some have their own logging mechanism built on top of console.log. At most, some small sites will have short outages until people complain and the logging statements get fixed / removed.

The biggest share of the price of the current console.log isn't site breakage. It is slowing down the people who build sites, by not being as versatile as it could be. My story below (which you can skip) illustrates this.

<blahblah>
The first time I tried to use console.log as a callback, I was happy for realizing that it should work as a callback, since JavaScript is a functional language. Then I saw the Type error and realized what was going on. I was immediately curious if Firefox works the same way, so I opened it up and tried it there. Afterwards I figured I'm not going to bother writing "function(x) { console.log(x); }" (didn't think of bind() on the spot, it's not that much easier to type though). So I moved back to my editor, added a logging statement, and refreshed the page. By the end of this, my flow was interrupted.

Next time (a few months later) I bumped into another case where I'd have liked to pass console.log to a callback, I checked quickly to see if it still throws a TypeError, grumbled and moved on. Later, I stumbled upon the Chromium bug, and a few days ago I stumbled upon the issue again, and was in a good position to address it.
</blahblah>

The main takeaway here is that most developers running into this won't consider it serious enough to complain about. It's just a tiny hurdle, but removing tiny hurdles can add up to quite a bit in the long run.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.