Static console functions / binding #3

terinjokes · 2014-09-24T06:12:19Z

Right now assigning a console function to a local variable kind of sucks, since they're expected to be called within the context of console. This requires the developer to bind.

var log = console.log.bind(console);
log('＼(゜ロ＼)ココハドコ? (／ロ゜)／アタシハダアレ?');

Except this doesn't work in some versions of IE because the console functions aren't instances of Function!

var log = Function.prototype.bind.call(console.log, console);
log('(ノಠ益ಠ)ノ彡┻━┻');

Which is a lot to type for a pretty simple and common task.

var log = console.log;
log('＼(◎o◎)／！');

It makes sense to me that this is soemthing worth supporting.

The text was updated successfully, but these errors were encountered:

sindresorhus · 2016-01-08T15:28:58Z

👍 This is very convenient when you want to log the output of a callback .catch(console.error) or create a shortcut const log = console.log. This is also how it works in Node.js.

domenic · 2016-01-10T22:08:38Z

I don't think any browsers currently support this, although Node.js does. I think it's sensible, but I think we'd have some work to do before getting it in browsers:

Web IDL would need to be updated with some kind of [Bound] attribute. Hmm, I wonder if [Unforgeable] would work? It wasn't meant for that purpose, but seems worth checking...
We'd need to get at least a couple browsers to implement that.

alexkozy · 2016-01-12T21:50:57Z

FYI.
Link to chromium discussion about this: https://crbug.com/167911
And older and more informative webkit issue: https://bugs.webkit.org/show_bug.cgi?id=20141#c40

pwnall · 2016-01-12T23:20:29Z

I'd be happy to try to revisit WebKit and Blink implementations for bound console.log and its siblings if the standard goes in that direction. I'm still a bit annoyed when I can't pass console.log as a callback when debugging or feeling my way around new browser features, so I'd be sufficiently motivated to get it implemented.

paulirish · 2016-01-17T02:20:05Z

Chrome DevTools team discussed this yesterday and it's doable though more work than it appears to be. These methods are implemented in native, rather than JS. We may fix this in the next few months, though we'd be happy for your help with it @pwnall

domenic · 2016-01-17T02:35:48Z

@paulirish one approach that the spec might consider is to change the IDL from

[NoInterfaceObject]
interface Console {
  void assert(boolean condition, optional any message);
  void clear();
  ...
};

partial interface Window {
  attribute Console console;
};

to

// [NoInterfaceObject is gone]
interface console { // note lowercase
  static void assert(boolean condition, optional any message);
  static void clear();
};

// no need for adding it to Window explicitly

This would change things slightly: typeof window.console === "function" would now be true, among the obvious prototype chain changes (i.e. there's no Console.prototype object). But maybe run that by your team and see what they think.

The alternative would be custom bindings of a sort.

pwnall · 2016-01-19T17:56:39Z

@paulirish @domenic Is this definitely going to happen in spec-land? I'm asking to make sure I don't waste effort trying to implement it. If so, I can probably find some time in the second half of February. Also, 🎆

domenic · 2016-01-19T18:06:48Z

@pwnall well, specs are driven by implementation willingness, so that question is kind of backward. If we can get at least two implementations to pledge to implement something then we can in good conscience put it in the spec.

robertkowalski · 2016-01-29T22:02:42Z

a typical chicken-egg situation. :)

@frewsxcv what do you think about it in regard to FF?

frewsxcv · 2016-01-29T22:08:46Z

For the record, I'm not in any way associated with Mozilla, other than occasional volunteer contributions for Servo. I'll link this thread to the Servo/Firefox people hoping someone more official will answer.

jlongster · 2016-01-29T22:21:53Z

Apparently we (Firefox) used to do this. I found this: https://bugzilla.mozilla.org/show_bug.cgi?id=989619

I can't speak for my team (devtools) but I bet most people would be fine with this. My coworker also filed this bug a while bug on a (seemingly defunct) different console repo: DeveloperToolsWG/console-object#27

domenic · 2016-02-09T16:44:22Z

OK, so as discussed in #1 (comment) and the related mailing list thread, this issue is kind of the biggest outstanding issue on this repo. And it's essentially blocked on implementer interest. Web developers really want this, as can be seen from previous discussions.

My sketch in #1 (comment) shows how this can be done without any custom IDL bindings, which should ease the burden on implementers. But we still need at the very least explicit signals from two implementers that they are willing to do the work.

It seems like from #3 (comment) there's some support from Chrome, on the timeline of a few months, and in https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Feb/0007.html it seems like @bzbarsky voiced support if someone can volunteer to do the work in Firefox. I wouldn't say this is enough support to conclusively change the spec yet though... it would be different if someone from Firefox could commit to doing the work.

Any thoughts from Safari (@hober?) or Microsoft (@travisleithead?)?

zcorpan · 2016-02-10T04:58:57Z

If this is implementable with only copying webidl, it seems like it could be a "good first bug" for Firefox that @bzbarsky could mentor, maybe? Is there a bug filed?

Just changing the spec could also get the ball rolling...

bzbarsky · 2016-02-10T14:44:04Z

This is not a "good first bug". It requires some tricky under-the-hood changes to the console implementation in Gecko (due to no longer having an actual Console object), and especially to its interactions with memory management and the garbage collector. It wouldn't be so bad if console only existed on the main thread, but its existence on workers, and the ensuing need to communicate to the main-thread console, make all this very much not a "good first bug".

So the real problem on the Gecko end is that the set of people who could quickly (a few days of work) fix this is very limited and they're all busy with other things...

RReverser · 2016-02-10T15:07:09Z

due to no longer having an actual Console object

I don't know the Gecko internals, but would be it possible to make this an implementation detail for now? (like, leave Console object, but auto-bind methods when exposing)

bzbarsky · 2016-02-10T15:16:09Z

That would be even harder, with a smaller pool of people who can do it, actually; all that stuff is completely automated right now via the bindings generator and would require some fundamental changes to the generator to introduce that sort of hack.

Anyway, my points are: 1) this is not something we're likely to prototype quickly, and hence not likely to invest effort into unless we're pretty sure it should be done. 2) Even once we're sure it should be done it's likely to take a few months to get to it.

domenic · 2016-02-10T15:17:57Z

@bzbarsky would "we're pretty sure it should be done" be influenced by changing the spec? I'd prefer to be conservative and not change without implementer support, but I recognize there's a potential chicken-egg problem here, depending on how adventurous implementers are feeling.

bzbarsky · 2016-02-10T15:18:39Z

would "we're pretty sure it should be done" be influenced by changing the spec?

Probably not; it would be influenced by other implementors committing to doing it...

foolip · 2016-03-07T04:46:09Z

function log() { console.log.apply(console, arguments); } works in Edge, but which versions of IE was there a problem with console.log not being a function? Whatever the answer, this can't be remedied by updating Edge and other engines.

Is this situation substantially different from, say, document.createElement?

domenic · 2016-03-07T04:49:02Z

@foolip I think the difference is largely that developers have been asking for this for a long time, and behaviors in old-Firefox and in Node.js influenced them to expect it. The common case is arr.forEach(console.log) or similar.

foolip · 2016-03-07T05:03:53Z

Oh, Node.js, I skimmed past that. Going with statics would make it similar to CSS.supports, although having an interface called console would be quite unusual. WebKit seems to implement console without using IDL now, maybe it would be worth a look: http://trac.webkit.org/changeset/165199

alexkozy · 2016-04-25T19:17:05Z

ToT Chromium supports calls to console related methods without console: crbug.com/167911 is fixed.

bzbarsky · 2016-04-25T19:21:31Z

Er, with what behavior? Is there still a window.Console, for example? @domenic

domenic · 2016-04-25T19:27:26Z

Woah. Browsing https://codereview.chromium.org/1859293002 it looks like they've made major changes which are not at all aligned with other browsers, like moving to a data property instead of a getter/replaceable setter on the prototype. That seems quite bad.

I can't tell about window.Console right now.

bzbarsky · 2016-04-25T19:37:37Z

@domenic Can you talk to whoever is involved and figure out what the story is, please? ;)

alexkozy · 2016-04-25T21:05:24Z

I've attached screenshot of window.console output in Chrome and Mozilla. In the both implementation we have Console object with ConsolePrototype that contains all console related methods. And it's better then was before when in Chrome we have Console with ConsoleBase prototype.
console is replaceable and each property is replaceable. I can't see the different between replaceble setter/getter and attribute. Could you figure out this?
window.Console behavior wasn't changed in Chrome it is still undefined but we can define it with constructor if necessary.

bzbarsky · 2016-04-25T21:23:12Z

and each property is replaceable.

Replaceable in what sense? In Gecko you can set console.log = whatever and this will shadow the prototype property, obviously, but Console.prototype.log will still be the original thing, of course. If you're putting props on a prototype in Chrome, that should give the same behavior, obviously.

There shouldn't be any getters/setters here, because Console has no attributes, only methods ("operations" in IDL-speak).

domenic · 2016-04-25T21:42:42Z

There's the question of what Object.getOwnPropertyDescriptor(window, "console") returns. That is what is changed by the Chrome patch to be incompatible with other browsers.

domenic · 2016-05-18T23:36:01Z

This seems like something we'd need implementers to decide on.

Per that bug, WebKit has gone with adding an empty object named __proto__ to console. (If I were to spec that, I'd probably add an extended attribute [LegacyDummyProto] for use on namespaces, which hopefully only console would ever use; with luck CSS could get away without it.)

But how does Gecko feel about the potential compatibility hit? How does Chrome? (@paulirish @ak239) Edge? (@andysterland) If most browsers are interested in pushing through without such a hack, we probably shouldn't spec it, but I don't really know yet.

domenic · 2016-05-18T23:40:31Z

Oh, and there's two potential hacks here:

(A) Make console's [[Prototype]] a new empty object
(B) Add an own property named "__proto__" whose value is an empty object.

(The difference is observable because for (A), Object.getPrototypeOf(console) will return the empty object; for (B) it will return Object.prototype.)

WebKit seems to have gone with (A). I was originally thinking that (B) would be better, but upon reflection it's probably too weird and could potentially cause compatibility issues.

Note that neither (A) nor (B) really fixes the original demo code shown by @JosephPecoraro:

console.__proto__.debug = function(format) {
    if (window.DEBUG) {
        var varargs = Array.prototype.slice.call(arguments);
        console.__proto__.info.apply(this, varargs)
    }
}

I believe that this will still fail, once it reaches the line console.__proto__.info.apply(this, varargs). Maybe that line is reached more rarely than the for-in he talked about, though.

JosephPecoraro · 2016-05-19T00:14:19Z

I believe that this will still fail, once it reaches the line console.__proto__.info.apply(this, varargs)

We were aware of the possible issue, but were fine with the trade offs.

You are correct that the apply would fail, but in practice it is unlikely to be reached. This particular page doesn't seem to call console.debug anywhere or make use of its new function by any other name. However, were the page were to do console.debug("foo") (which we considered the most likely use) it would use the unaffected native console.debug on the namespace object and not the fragile console.__proto__.debug the page defined.

zcorpan · 2016-05-19T10:01:49Z

@domenic if the hack is a one-off, it can be prose in the console spec rather than new extended attribute in Web IDL.

zcorpan · 2016-05-19T10:20:30Z

I did a quick search in httparchive (494k pages), only 3 resources that do __proto__ or getPrototypeOf on console or CSS.

SELECT COUNT(*) AS num, REGEXP_EXTRACT(body, r'(\b(?:(?:CSS|console)\.__proto__|getPrototypeOf\(\s*(?:[a-zA-Z]+\.)*(?:CSS|console)\s*\)).*)') as match
FROM [httparchive:har.2016_04_15_chrome_requests_bodies]
GROUP BY match
ORDER BY num DESC

Row	num	match
1	17616995	null
2	1	`console.proto.debug=function(format){if(window.DEBUG){var varargs=Array.prototype.slice.call(arguments);console.proto.info.apply(this,varargs)}},_mu.utils.renderTemplate=function(elementId,data,namespace){if("string"!=typeof elementId
3	1	`console.proto;.each(.keys(functions),function(key){if(typeof functions[key]=="function"){this[key]=function(){if(self.logging){console[key].apply(console,arguments)}};self.enabled[key]=true}},this)}else{window.console=this}.each(consoleInterface,function(functionName){if(this[functionName]===undefined){this[functionName]=function(){};self.enabled[functionName]=false}},this)}})(window,window.jQuery,window.,window.console,window.SiteTools.Core);Namespace("SiteTools.Core");(function(window,$,,console,core){window.SiteTools.Core.Event=new function(){var self=this;this.logging=true;this.log=function(groupTitle,groupArgs){if(this.logging){if(core.Console.enabled.groupCollapsed){console.groupCollapsed(groupTitle);if(core.Console.enabled.dir){console.dir(groupArgs)}else{console.log(groupArgs)}console.groupEnd()}else{console.log(groupTitle)}}};this.Bindings=[];this.Trigger=function(event,args){self.log(String.Format("Event '{0}' triggered",event),{"Arguments":args});var curBindings=.filter(this.Bindings,function(binding){return binding.event==event});.every(this.Bindings,function(binding){if(binding.context.nodeName&&binding.context!==window.document){if(!$(binding.context).closest("html").length){self.Unbind(binding.event,binding.eventHandler,binding.context)}}});.every(curBindings,function(binding){var eventArgs={type:event,data:args,cancelBubble:false};binding.eventHandler.call({},eventArgs);if(eventArgs.cancelBubble===true){self.log(String.Format("Event bubble canceled for event '{0}'",event),{"Arguments":eventArgs});return false}else{return true}});if(event!="EventTrigger"){this.Trigger("EventTrigger",{type:event,data:args})}};this.Bind=function(event,eventHandler,context){context=context
4	1	`console.proto;.each(.keys(functions),function(key){if(typeof functions[key]=="function"){this[key]=function(){if(self.logging){console[key].apply(console,arguments)}};self.enabled[key]=true}},this)}else{window.console=this}.each(consoleInterface,function(functionName){if(this[functionName]===undefined){this[functionName]=function(){};self.enabled[functionName]=false}},this)}})(window,window.jQuery,window.,window.console,window.SiteTools.Core);Namespace("SiteTools.Core");(function(window,$,,console,core){window.SiteTools.Core.Event=new function(){var self=this;this.logging=true;this.log=function(groupTitle,groupArgs){if(this.logging){if(core.Console.enabled.groupCollapsed){console.groupCollapsed(groupTitle);if(core.Console.enabled.dir){console.dir(groupArgs)}else{console.log(groupArgs)}console.groupEnd()}else{console.log(groupTitle)}}};this.Bindings=[];this.Trigger=function(event,args){self.log(String.Format("Event '{0}' triggered",event),{Arguments:args});var curBindings=.filter(this.Bindings,function(binding){return binding.event==event});.every(this.Bindings,function(binding){if(binding.context.nodeName&&binding.context!==window.document){if(!$(binding.context).closest("html").length){self.Unbind(binding.event,binding.eventHandler,binding.context)}}});.every(curBindings,function(binding){var eventArgs={type:event,data:args,cancelBubble:false};binding.eventHandler.call({},eventArgs);if(eventArgs.cancelBubble===true){self.log(String.Format("Event bubble canceled for event '{0}'",event),{Arguments:eventArgs});return false}else{return true}});if(event!="EventTrigger"){this.Trigger("EventTrigger",{type:event,data:args})}};this.Bind=function(event,eventHandler,context){context=context

alexkozy · 2016-05-20T18:08:03Z

In Chrome we'd like to fix problem with console.proto as soon as possible and are going to land (A) as temporary solution.
I think that we can add a warning message when someone set something on console.proto .

danzen · 2016-06-19T01:12:41Z

Hi folks, over the last couple of versions of Firefox, the binding of console.log is no longer giving the file and line numbers in very right hand column of the console. It now says (unknown). Other browsers still work. Is there a way for me to solve this as it is important for my public library http://zimjs.com. I am using:

var log = console.log.bind(console);

also tried with no success:

var log = Function.prototype.bind.call(console.log, console);

Thank you!

domenic · 2016-06-19T02:16:54Z

@danzen that seems unrelated to this issue; I'd suggest filing a bug on the Firefox issue tracker, not commenting on an issue on the console standard.

danzen · 2016-06-19T17:21:30Z

@domenic thanks - I think I did that a few weeks ago - I will check on that... sorry did not realize that this was for standards. Cheers for all your work. Just looked and could not find my bug report. So added another: https://bugzilla.mozilla.org/show_bug.cgi?id=1280818#c0 if you are interested!

* Add namespaces This adds the concept of namespaces, as discussed in whatwg/console#3 (starting especially around whatwg/console#3 (comment)). They can only contain regular operations. The ES binding for namespaces here is written in a fully modern style, and so differs slightly from similar prose for interfaces' ES binding. It is hoped that it can provide a template for eventually updating interfaces' ES binding to modern ES. * Address most code review comments: - Missing some [SecureContext] stuff - Not yet addressed the operation-creation stuff * Stick with "declared on" instead of "declared within" It doesn't read quite right to me, but let's keep it as-is for now and investigate any issues in #153. * Move "creating an operation function" out to #es-operations

domenic · 2016-10-17T23:24:45Z

Thanks everyone for your help along this long journey! The spec is now updated, including the special prototype object.

Web platform tests are up at Test that console is a namespace web-platform-tests/wpt#3994
Edge bug filed at https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/9392959/
Chrome bug tracker currently inaccessible, but here is a non-canonical URL of the bug for Chrome's enumerability: https://monorail-prod.appspot.com/p/chromium/issues/detail?id=656826

From the WHATWG console spec: > For historical web-compatibility reasons, the namespace object for > console must have as its [[Prototype]] an empty object, created as > if by ObjectCreate(%ObjectPrototype%), instead of %ObjectPrototype%. Since in Node.js, the Console constructor has been exposed through require('console'), we need to keep the Console constructor but we cannot actually use `new Console` to construct the global console. This patch changes the prototype chain of the global console object, the console.Console.prototype is not in the global console prototype chain anymore, which means ``` global.console instanceof global.console.Console ``` is no longer true after this patch. This fixes a case in the console Web Platform Test that we commented out. Refs: https://console.spec.whatwg.org/#console-namespace Refs: whatwg/console#3

From the WHATWG console spec: > For historical web-compatibility reasons, the namespace object for > console must have as its [[Prototype]] an empty object, created as > if by ObjectCreate(%ObjectPrototype%), instead of %ObjectPrototype%. Since in Node.js, the Console constructor has been exposed through require('console'), we need to keep the Console constructor but we cannot actually use `new Console` to construct the global console. This patch changes the prototype chain of the global console object, so the console.Console.prototype is not in the global console prototype chain anymore. ``` const proto = Object.getPrototypeOf(global.console); // Before this patch proto.constructor === global.console.Console // After this patch proto.constructor === Object ``` But, we still maintain that ``` global.console instanceof global.console.Console ``` through a custom Symbol.hasInstance function of Console that tests for a special symbol kIsConsole for backwards compatibility. This fixes a case in the console Web Platform Test that we commented out. Refs: https://console.spec.whatwg.org/#console-namespace Refs: whatwg/console#3

From the WHATWG console spec: > For historical web-compatibility reasons, the namespace object for > console must have as its [[Prototype]] an empty object, created as > if by ObjectCreate(%ObjectPrototype%), instead of %ObjectPrototype%. Since in Node.js, the Console constructor has been exposed through require('console'), we need to keep the Console constructor but we cannot actually use `new Console` to construct the global console. This patch changes the prototype chain of the global console object, so the console.Console.prototype is not in the global console prototype chain anymore. ``` const proto = Object.getPrototypeOf(global.console); // Before this patch proto.constructor === global.console.Console // After this patch proto.constructor === Object ``` But, we still maintain that ``` global.console instanceof global.console.Console ``` through a custom Symbol.hasInstance function of Console that tests for a special symbol kIsConsole for backwards compatibility. This fixes a case in the console Web Platform Test that we commented out. PR-URL: #23509 Refs: whatwg/console#3 Refs: https://console.spec.whatwg.org/#console-namespace Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: John-David Dalton <[email protected]>

From the WHATWG console spec: > For historical web-compatibility reasons, the namespace object for > console must have as its [[Prototype]] an empty object, created as > if by ObjectCreate(%ObjectPrototype%), instead of %ObjectPrototype%. Since in Node.js, the Console constructor has been exposed through require('console'), we need to keep the Console constructor but we cannot actually use `new Console` to construct the global console. This patch changes the prototype chain of the global console object, so the console.Console.prototype is not in the global console prototype chain anymore. ``` const proto = Object.getPrototypeOf(global.console); // Before this patch proto.constructor === global.console.Console // After this patch proto.constructor === Object ``` But, we still maintain that ``` global.console instanceof global.console.Console ``` through a custom Symbol.hasInstance function of Console that tests for a special symbol kIsConsole for backwards compatibility. This fixes a case in the console Web Platform Test that we commented out. PR-URL: nodejs#23509 Refs: whatwg/console#3 Refs: https://console.spec.whatwg.org/#console-namespace Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: John-David Dalton <[email protected]>

From the WHATWG console spec: > For historical web-compatibility reasons, the namespace object for > console must have as its [[Prototype]] an empty object, created as > if by ObjectCreate(%ObjectPrototype%), instead of %ObjectPrototype%. Since in Node.js, the Console constructor has been exposed through require('console'), we need to keep the Console constructor but we cannot actually use `new Console` to construct the global console. This patch changes the prototype chain of the global console object, so the console.Console.prototype is not in the global console prototype chain anymore. ``` const proto = Object.getPrototypeOf(global.console); // Before this patch proto.constructor === global.console.Console // After this patch proto.constructor === Object ``` But, we still maintain that ``` global.console instanceof global.console.Console ``` through a custom Symbol.hasInstance function of Console that tests for a special symbol kIsConsole for backwards compatibility. This fixes a case in the console Web Platform Test that we commented out. PR-URL: #23509 Refs: whatwg/console#3 Refs: https://console.spec.whatwg.org/#console-namespace Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: John-David Dalton <[email protected]>

From the WHATWG console spec: > For historical web-compatibility reasons, the namespace object for > console must have as its [[Prototype]] an empty object, created as > if by ObjectCreate(%ObjectPrototype%), instead of %ObjectPrototype%. Since in Node.js, the Console constructor has been exposed through require('console'), we need to keep the Console constructor but we cannot actually use `new Console` to construct the global console. This patch changes the prototype chain of the global console object, so the console.Console.prototype is not in the global console prototype chain anymore. ``` const proto = Object.getPrototypeOf(global.console); // Before this patch proto.constructor === global.console.Console // After this patch proto.constructor === Object ``` But, we still maintain that ``` global.console instanceof global.console.Console ``` through a custom Symbol.hasInstance function of Console that tests for a special symbol kIsConsole for backwards compatibility. This fixes a case in the console Web Platform Test that we commented out. PR-URL: nodejs#23509 Refs: whatwg/console#3 Refs: https://console.spec.whatwg.org/#console-namespace Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: John-David Dalton <[email protected]>

@zloirock

Turning ``this`` from ``null`` to ``console`` accorging to whatwg/console#3 to avoid issues under antique engines Thanks again to @zloirock for mentioning this

@zloirock

Turning ``this`` from ``null`` to ``console`` accorging to whatwg/console#3 to avoid issues under antique engines Thanks again to @zloirock for mentioning this

@zloirock

Turning ``this`` from ``null`` to ``console`` accorging to whatwg/console#3 to avoid issues under antique engines Thanks again to @zloirock for mentioning this

sindresorhus mentioned this issue Jan 8, 2016

Possibly unnecessary code? nodejs/node#4581

Closed

domenic mentioned this issue Feb 9, 2016

Investigate if console in partial interfaces should be mutable #1

Closed

bzbarsky mentioned this issue Aug 24, 2016

console should be a namespace, not an interface instance servo/servo#13010

Closed

terinjokes closed this as completed in 9a0792d Oct 17, 2016

falsandtru mentioned this issue Oct 31, 2016

Functionalize console methods polyfillpolyfill/polyfill-service#967

Closed

hsablonniere mentioned this issue Jan 9, 2018

Only use console.log & console.error CleverCloud/clever-tools#177

Merged

jackhorton mentioned this issue Mar 7, 2018

console.log passed as function value fails chakra-core/ChakraCore#4787

Closed

joyeecheung mentioned this issue Oct 12, 2018

lib: make the global console [[Prototype]] an empty object nodejs/node#23509

Closed

3 tasks

bakkot mentioned this issue Feb 6, 2020

Add spec text to be compatible with WebCrypto tc39/proposal-csprng#2

Draft

rbuckton mentioned this issue Feb 6, 2020

'getRandomValues' in WebCrypto throws if receiver isn't a 'Crypto' instance. tc39/proposal-csprng#4

Open

Static console functions / binding #3

Static console functions / binding #3

Comments

terinjokes commented Sep 24, 2014

sindresorhus commented Jan 8, 2016

domenic commented Jan 10, 2016

alexkozy commented Jan 12, 2016

pwnall commented Jan 12, 2016

paulirish commented Jan 17, 2016

domenic commented Jan 17, 2016

pwnall commented Jan 19, 2016

domenic commented Jan 19, 2016

robertkowalski commented Jan 29, 2016

frewsxcv commented Jan 29, 2016

jlongster commented Jan 29, 2016

domenic commented Feb 9, 2016

zcorpan commented Feb 10, 2016

bzbarsky commented Feb 10, 2016

RReverser commented Feb 10, 2016

bzbarsky commented Feb 10, 2016

domenic commented Feb 10, 2016

bzbarsky commented Feb 10, 2016

foolip commented Mar 7, 2016

domenic commented Mar 7, 2016

foolip commented Mar 7, 2016

alexkozy commented Apr 25, 2016

bzbarsky commented Apr 25, 2016

domenic commented Apr 25, 2016

bzbarsky commented Apr 25, 2016

alexkozy commented Apr 25, 2016

bzbarsky commented Apr 25, 2016

domenic commented Apr 25, 2016

domenic commented May 18, 2016 • edited Loading

domenic commented May 18, 2016

JosephPecoraro commented May 19, 2016

zcorpan commented May 19, 2016

zcorpan commented May 19, 2016

alexkozy commented May 20, 2016 • edited Loading

danzen commented Jun 19, 2016

domenic commented Jun 19, 2016

danzen commented Jun 19, 2016 • edited Loading

domenic commented Oct 17, 2016

domenic commented May 18, 2016 •

edited

Loading

alexkozy commented May 20, 2016 •

edited

Loading

danzen commented Jun 19, 2016 •

edited

Loading