Por que o depurador do Chrome acha que a variável local fechada é indefinida?

Com este código:

function baz() {
  var x = "foo";

  function bar() {
    debugger;
  };
  bar();
}
baz();

Eu recebo este resultado inesperado:

Quando eu mudo o código:

function baz() {
  var x = "foo";

  function bar() {
    x;
    debugger;
  };
  bar();
}

Eu recebo o resultado esperado:

Além disso, se houver alguma chamada para evaldentro da função interna, eu posso acessar minha variável como desejo (não importa para o que eu passo eval).

Enquanto isso, as ferramentas de desenvolvimento do Firefox fornecem o comportamento esperado nas duas circunstâncias.

O que há com o Chrome que o depurador se comporte menos do que o Firefox? Eu observo esse comportamento há algum tempo, incluindo a versão 41.0.2272.43 beta (64 bits).

Será que o mecanismo javascript do Chrome "nivela" as funções quando pode?

Curiosamente, se eu adicionar uma segunda variável que é referenciada na função interna, a xvariável ainda está indefinida.

Entendo que muitas vezes existem peculiaridades com escopo e definição de variável ao usar um depurador interativo, mas parece-me que, com base na especificação da linguagem, deve haver uma "melhor" solução para essas peculiaridades. Portanto, estou muito curioso se isso se deve à otimização do Chrome para além do Firefox. E também se essas otimizações podem ou não ser facilmente desabilitadas durante o desenvolvimento (talvez elas devam ser desabilitadas quando as ferramentas de desenvolvimento estão abertas?).

Além disso, eu posso reproduzir isso com pontos de interrupção e com a debuggerdeclaração.

Encontrei um relatório de problema da v8 que é exatamente sobre o que você está perguntando.

Agora, para resumir o que é dito nesse relatório de problema ... a v8 pode armazenar as variáveis ​​locais para uma função na pilha ou em um objeto de "contexto" que fica na pilha. Ele alocará variáveis ​​locais na pilha, desde que a função não contenha nenhuma função interna que se refira a elas. É uma otimização . Se qualquer função interna se referir a uma variável local, essa variável será colocada em um objeto de contexto (ou seja, na pilha em vez de na pilha). O caso de evalé especial: se é chamado de alguma forma por uma função interna, todas as variáveis ​​locais são colocadas no objeto de contexto.

A razão para o objeto de contexto é que, em geral, você pode retornar uma função interna da externa e, em seguida, a pilha que existia enquanto a função externa era executada não estará mais disponível. Portanto, qualquer coisa acessada pela função interna precisa sobreviver à função externa e viver na pilha, e não na pilha.

O depurador não pode inspecionar as variáveis ​​que estão na pilha. Com relação ao problema encontrado na depuração, um Membro do Projeto diz :

A única solução em que pude pensar é que sempre que o devtools estiver ativado, desoptamos todo o código e recompilamos com a alocação forçada de contexto. Isso regrediria drasticamente o desempenho com os devtools ativados.

Aqui está um exemplo do "se alguma função interna se refere à variável, coloque-a em um objeto de contexto". Se você executar isso, poderá acessar xa debuggerinstrução mesmo que xseja usada apenas na foofunção, que nunca é chamada !

function baz() {
  var x = "x value";
  var z = "z value";

  function foo () {
    console.log(x);
  }

  function bar() {
    debugger;
  };

  bar();
}
baz();

Como o @Louis disse, causado por otimizações da v8. Você pode atravessar a pilha de chamadas para o quadro em que essa variável está visível:

Ou substitua debuggerpor

eval('debugger');

eval vai adiar pedaço atual

Eu também notei isso no nodejs. Acredito (e admito que isso é apenas um palpite) que, quando o código é compilado, se xnão aparecer dentro bar, ele não fica xdisponível dentro do escopo de bar. Isso provavelmente o torna um pouco mais eficiente; o problema é que alguém esqueceu (ou não se importava) que, mesmo se não há é xem bar, você pode optar por executar o depurador e, portanto, ainda precisa de acesso xa partir de dentro bar.

Uau, muito interessante!

Como outros já mencionaram, isso parece estar relacionado scope, mas mais especificamente, a debugger scope. Quando o script injetado é avaliado nas ferramentas do desenvolvedor, parece determinar a ScopeChain, o que resulta em alguma peculiaridade (já que está vinculado ao escopo do inspetor / depurador). Uma variação do que você postou é o seguinte:

(EDIT - na verdade, você mencionou isso na sua pergunta original, caramba, meu mal! )

function foo() {
  var x = "bat";
  var y = "man";

  function bar() {
    console.log(x); // logs "bat"

    debugger; // Attempting to access "y" throws the following
              // Uncaught ReferenceError: y is not defined
              // However, x is available in the scopeChain. Weird!
  }
  bar();
}
foo();

Para os ambiciosos e / ou curiosos, escopo (heh) a fonte para ver o que está acontecendo:

https://github.com/WebKit/webkit/tree/master/Source/JavaScriptCore/inspector https://github.com/WebKit/webkit/tree/master/Source/JavaScriptCore/debugger

Suspeito que isso tenha a ver com o levantamento de variáveis ​​e funções. JavaScript traz todas as declarações de variáveis ​​e funções para o topo da função em que estão definidas. Mais informações aqui: http://jamesallardice.com/explaining-function-and-variable-hoisting-in-javascript/

Aposto que o Chrome está chamando o ponto de interrupção com a variável indisponível para o escopo, porque não há mais nada na função. Isso parece funcionar:

function baz() {
  var x = "foo";

  function bar() {
    console.log(x); 
    debugger;
  };
  bar();
}

Como faz isso:

function baz() {
  var x = "foo";

  function bar() {
    debugger;
    console.log(x);     
  };
  bar();
}

Espero que isso e / ou o link acima ajude. Este é o meu tipo favorito de perguntas sobre SO, BTW :)