928001 - console.dir displaying data from after it has been launched

Status: RESOLVED DUPLICATE of bug 754861

(DevTools :: Console, defect, P3)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

This code:

var localesToDownload = [];
console.dir(localesToDownload);

and later:

localesToDownload.push('fr');

displays console.dir with 'fr' element that was not in the array when console.dir has been called.

Very high WTF factor reported.

Comment 1

[Mihai Sucan [:msucan]]

The console API is async and we do not copy objects, so you always get the latest content of the object you log, at the time the output is built.

The same happens with console.log(foo) and other methods.

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

STR:

  obj = { a: 1}; console.dir(obj); obj.a++

Comment 3

[Brandon Benvie [:benvie]]

We talked about this, and we think developers expect console.log/dir to show them the object at the time the exact time they do the logging. Deep copy snapshotting would probably be too much of a performance hit, so we'd like to shallow copy the properties one level deep at the time of execution. Expanding subproperties would then show live data. This is an acceptable compromise between performance and utility.

Comment 4

[Joe Walker [:jwalker]]

How would people know that we were doing a shallow clone? Maybe we could have a different color for 'live' values or something?

Doesn't this just move the problem to:

  obj = { a: { b: 1 }}; console.dir(obj); obj.a.b++

Comment 5

[Joe Walker [:jwalker]]

Attachment: ScreenShot.png

FWIW, Chrome's solution. I'm not sure they got it right but I think it needs something visual to tell the user what is cloned and what isn't.

When you hover the [i] it says "Object state below is captured on first expansion". I wonder how deep they go on that...

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

From a web dev POV both approaches are valuable for different purposes.

It would be awesome to have a second param that allows me to control wherever I get a snapshot from the moment or live view of the object.

Comment 7

[Joe Walker [:jwalker]]

(In reply to Zbigniew Braniecki [:gandalf] from comment #6)
> From a web dev POV both approaches are valuable for different purposes.

When is it useful to have live data? (Given that you can always repeat the console function call) I thought that we wanted was static data, but we couldn't do that for perf reasons so we were getting as close as we could.

> It would be awesome to have a second param that allows me to control
> wherever I get a snapshot from the moment or live view of the object.

Yeah, our trouble is that there are too many incompatible versions of the console API already. :(

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

(In reply to Joe Walker [:jwalker] from comment #7)
> (In reply to Zbigniew Braniecki [:gandalf] from comment #6)
> > From a web dev POV both approaches are valuable for different purposes.
> 
> When is it useful to have live data? (Given that you can always repeat the
> console function call) I thought that we wanted was static data, but we
> couldn't do that for perf reasons so we were getting as close as we could.

Yeah, I reported the bug because the numbers I was getting were inconsistent with my expectations. I would say that in vast majority of cases, the developer is expecting to see a static dump of the object data.

I could see a benefit of a live object for code like this:

var a = {b: 1};
console.dir(a, true); // second param makes the object in the console live

document.getElementById('button').addEventListener('click', function(e) {
  a.b++;
});

To see how the value of the object reacts to other activities - it seems nicer to track it this way instead of putting console.dir inside the event handler and firing it on each change, but that's a minority case, way less important.

> > It would be awesome to have a second param that allows me to control
> > wherever I get a snapshot from the moment or live view of the object.
> 
> Yeah, our trouble is that there are too many incompatible versions of the
> console API already. :(

Sure, in that case I'd say that it's important to make sure that the data in console.dir dump matches the data in the object from the moment when the console.dir has been fired.

Comment 9

[Thoka]

Besides the performance considerations.
I spend some time teaching kids javascript. For them( and most entry level programmers, i guess ) the console is the prefered debugging tool. Every time this inconsistency shows up they tend to lose trust in their abilities.
When i explain to them that their code is valid they always complain about having to work with a defective platform. 
I know this is more of an reception issue. But it would be sad to lose ambitious newbies to an obviously obscure behaviour.

Comment 10

[Mihai Sucan [:msucan]]

console.dir is part of the console API and we do not make any kind of object copies when you log any message. This may change in the future. Thanks to everyone for their feedback - let's continue the discussion in bug 754861.

Comment 11

[noitidart]

I read you guys may implement only 1 level deep (shallow copy), for many of my instances this won't help. So can you maybe ship a function which takes a first argument of intenger, and this will tell it how many levels deep to copy. like: `console.log(10, 'blah', 'blah', fooObj, anotherObj);`

with warning that if you go more than 0 (default) you will get neg perf impact