Why isn't `toString` equivalent to `window.toString`?

I’d believed that all global variables were accessible from the global object. So if I can access x (and x isn’t bound locally), then window.x is the same value.

However, in a webpage (on JSFiddle):

  • How to safely wrap `console.log`?
  • Display web console on screen?
  • Possible to enable “strict mode”; in FireBug and Chrome's console?
  • TypeError: Illegal Invocation on console.log.apply
  • ignore firebug console when not installed
  • How can I debug variables by console which bind to the controller by controllerAs in AngularJS
  • window === this // true in Chrome and Firefox
    toString === window.toString // true in Chrome and Firefox
    

    But in the console:

    window === this // true in Chrome console and Firebug, false in Firefox web console
    toString === window.toString // false in Chrome, Firebug and Firefox web console
    

    Why is this? Why is window the global object in Chrome’s console but toString not bound to window.toString? What is toString bound to in Firefox’s console? What other global values are different in the console?

  • JavaScript Console Output to Single Line with For and While Loop
  • Simple node.js readline on the console
  • Stylized console logging
  • adding custom functionality into chrome's console
  • Access all stored cookies
  • Command line tool for finding basic Javascript syntax errors?
  • 3 Solutions collect form web for “Why isn't `toString` equivalent to `window.toString`?”

    toString is not a global variable. It’s a method shared by almost all objects, including the window object.

    An actual global variable would always be available on the window object.

    perhaps this is related to this question?
    It’s all related to the context, I believe

    toString.call("foo") == this.toString.call("foo")
    

    but

    tostring.call("foot") != window.toString.call("foo") when this != window
    

    I cannot reproduce your claim in Firefox. They’re both returning [xpconnect wrapped native prototype].

    To help clear this up: everything available globally IS available via the global object. However, there could be properties available through the global object that are not necessarily available globally. This is due to the prototypal inheritance pattern in Javascript and the lack of specification on how this situation should be handled.

    So, should an interpreter attempt to resolve global lookups via prototypal inheritance down the global object chain? Does the global object inherit from anything else? I think the various Javascript interpreters are inconsistent here, but someone more familiar with ECMAScript specifications could weigh in.