Bug 35801 – Web Inspector: generate preview for the objects dumped into the console upon logging.

• Component: Web Inspector (Deprecated)
• Status: RESOLVED FIXED

[mitch kramer]

1) create an object literal with one or more properties
2) console.log that object but leave it closed (don't expand it in the console)
3) change one of the properties to a new value

now open that console.log and you'll see it has the new value for some reason, even though it's value was different at the time it was generated.

[mitch kramer]

I should point out that if you open it, it will retain the correct value if that wasn't clear.

[Pavel Feldman]

I don't think we are ever going to fix this one. We can't clone object upon dumping it into the console and we also can't listen to the object properties' changes in order to make it always actual.

We should make sure existing behavior is expected though.

[mitch kramer]

If i'm "logging it" It would seem that i would be taking a snapshot of it at that time... It seems broken to me to not have it be historical -- but if you can't do it, i guess you can't do it... just seems like it might be FAR more useful if it worked as I expected it to.

[mitch kramer]

Thinking about this further, it's odd that the behavior is different depending on whether or not you've expanded it or not... perhaps the fix is to have it expanded by default, since that keeps the correct data then. Chances are pretty good you're going to want to see that data anyway since you're console.logging it. Or maybe just perform those same operations in the background and not update the UI...

[Pavel Feldman]

(In reply to comment #4)
> Thinking about this further, it's odd that the behavior is different depending
> on whether or not you've expanded it or not... perhaps the fix is to have it
> expanded by default, since that keeps the correct data then. Chances are pretty
> good you're going to want to see that data anyway since you're console.logging
> it. Or maybe just perform those same operations in the background and not
> update the UI...

What if the inspected value is on the second level? In either case, for debugging purposes one can always use toString or JSON.stringify.

[mitch kramer]

(In reply to comment #5)
> What if the inspected value is on the second level? In either case, for
> debugging purposes one can always use toString or JSON.stringify.

That's fair enough, this behavior in general still feels wrong to me though. But if I stand alone in that, well, then, I guess I stand alone.

[André Hänsel]

(In reply to comment #2)
> I don't think we are ever going to fix this one. We can't clone object upon dumping it into the console and we also can't listen to the object properties' changes in order to make it always actual.

Why Firefox/Firebug can?

What use does the functionality of dumping objects have other than seeing the object *in the state it was in when being logged*?

[Quentin]

I agree with André.
This can lead to very strange log behaviour when your are not aware of this problem, such as http://stackoverflow.com/questions/8007397/javascript-constructor-with-google-chrome-bugged

[Nick S]

Here is another example of unexpected output for console.log()

http://jsfiddle.net/MeuXt/2/

You can see that toString() makes it output the correct value, but if you were to run that code without the toString(), you'd think that the array was somehow magically updated before the code was run on it.

[Timothy Hatcher]

*** Bug 75561 has been marked as a duplicate of this bug. ***

[Rohit Banga]

I saw a problem today which I suspect is related to this bug.

   eventHandler1: function(arr) {
      this.mainArr.push(arr);
      console.log(this.mainArr);    // prints correct array
   }

   eventHandler2: function() {
      console.log(this.mainArr);    // prints [undefined x 1]    ... WAT!!!
      var arr = this.mainArr.pop();
      // use and get rid of arr
   }

 
eventHandler2 is invoked a few seconds after eventHandler1.
Because of the pop() call the value of mainArr is printed as [undefined x 1] in eventHandler2. If I just comment the call to pop() then the value is printed correctly. It seems console.log() is resolving the reference after it has been GC'ed.

I also tried to invoke eventHandler2 immediately after eventHandler1 and managed to generate [undefined x 1] for both console.log() statements. So I would vaguely describe it as a race condition between GC and console renderer.

PS: Its 4 in the morning and I am too lazy to write a jsfiddle.

[Paul Irish]

Downstream ticket: http://crbug.com/50316

[Paul Irish]

*** Bug 49501 has been marked as a duplicate of this bug. ***

[Pavel Feldman]

Created attachment 156949 [details]
Patch

[Vsevolod Vlasov]

Comment on attachment 156949 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=156949&action=review

> Source/WebCore/inspector/InjectedScriptSource.js:714
> +    /** @param {!Object} object*/

nit: Please add new lines

> Source/WebCore/inspector/front-end/ConsoleMessage.js:322
> +            if (isArray && name === "length")

Why not skip it when creating an abbreviation?

> Source/WebCore/inspector/front-end/ConsoleMessage.js:327
> +

extra line

> Source/WebCore/inspector/front-end/ConsoleMessage.js:329
> +            if (!isArray || name != i) {

!==
When is this needed?

> Source/WebCore/inspector/front-end/ConsoleMessage.js:345
> +                span.textContent = "\"" + value.replace(/\n/g, "\u21B5") + "\"";

I think trimmed string should also cause isLosslessAbbreviation = false;

> Source/WebCore/inspector/front-end/ConsoleView.js:725
>                  return;

Please revert ConsoleView changes, as they were reviewed in another bug.

[Pavel Feldman]

Created attachment 157204 [details]
Patch

[Andrey Kosyakov]

Comment on attachment 157204 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=157204&action=review

> Source/WebCore/inspector/InjectedScriptSource.js:720
> +        var previewPropertyCount = 0;

where is this used?

[Andrey Kosyakov]

Comment on attachment 157204 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=157204&action=review

> Source/WebCore/inspector/front-end/ConsoleMessage.js:313
> +              isLosslessPreview = false;

indent

> Source/WebCore/inspector/front-end/ConsoleMessage.js:344
> +            if (type === "object") {
> +                var subtype = property[3];
> +                if (subtype === "node")
> +                    span.addStyleClass("console-formatted-preview-node");
> +                span.textContent = value;
> +            } else if (type === "string")
> +                span.textContent = "\"" + value.replace(/\n/g, "\u21B5") + "\"";
> +            else if (type === "null" || type === "undefined")
> +                span.textContent = type;
> +            else
> +                span.textContent = String(value);

switch (type)?

[Pavel Feldman]

Created attachment 157208 [details]
Patch

[Build Bot]

Comment on attachment 157208 [details]
Patch

Attachment 157208 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/13449848

[Andrey Kosyakov]

Comment on attachment 157208 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=157208&action=review

> Source/WebCore/inspector/InjectedScriptSource.js:775
> +            if (!preview.length)
> +                return undefined;

So what happens to empty arrays?

> Source/WebCore/inspector/front-end/ConsoleMessage.js:340
> +            } else if (type === "string")
> +                span.textContent = "\"" + value.replace(/\n/g, "\u21B5") + "\"";

This would turn 'a"b' into "a"b" which would looks a bit weird. I think if we're adding outer quotes, we should escape string to make it parseable.

[Pavel Feldman]

Created attachment 157228 [details]
Patch

[Vsevolod Vlasov]

Comment on attachment 157228 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=157228&action=review

> Source/WebCore/inspector/InjectedScriptSource.js:641
> +            return obj.nodeType === 1 /* Node.ELEMENT_NODE */ ? "<" + obj.nodeName.toLowerCase() + ">" : obj.nodeName.toLowerCase();

doctype?

> Source/WebCore/inspector/InjectedScriptSource.js:734
> +                    overflow = true;

Please add lossless = false

> Source/WebCore/inspector/InjectedScriptSource.js:753
> +                const maxLength = 20;

100?

> LayoutTests/inspector/console/console-format-expected.txt:58
> +[/^url\(\s*(?:(?:"(?:â¦] console-format.html:55

So regexps preview is lossy, we should add a tree view for such an object

> LayoutTests/inspector/console/console-format-expected.txt:77
> +<body onload="onload()"> console-format.html:54

This change looks somewhat unexpected for me. Did you intend to change the way elements are printed?

> LayoutTests/inspector/console/console-format.html:17
> +    array.foo = {}; 

Why did this change?

[Vsevolod Vlasov]

Comment on attachment 157228 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=157228&action=review

> LayoutTests/inspector/console/console-format-expected.txt:122
> +id="x""x"

I don't understand what is going on here. :(

[Build Bot]

Comment on attachment 157228 [details]
Patch

Attachment 157228 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/13454538

[Pavel Feldman]

Committed r125046: <http://trac.webkit.org/changeset/125046>

[Thiago Marcos P. Santos]

Created attachment 157264 [details]
Assertion backtrace

The EFL Debug bot is hitting this assertion after this patch.

[Pavel Feldman]

I'll roll it out.

[WebKit Review Bot]

Re-opened since this is blocked by 93505

[Pavel Feldman]

Landed as http://trac.webkit.org/changeset/125174

[Pieter Wigboldus]

Please check e.g. this in your console:

var s = ["hi"];
console.log(s);
s[0] = "bye";
console.log(s);

it show 2 times bye.
can be solved with 
console.log(s.toString());
or
console.log(s.slice());

In Firebug it show values that you expect, Chrome/Webkit show 2 times the last value.

[Pavel Feldman]

That's what this patch fixed.

[Rohit Banga]

Created attachment 177112 [details]
Screenshot showing that the length of an array is inconsistent.

I have an array called tabContent. I dump it to the console and its length. The length is now 1. The object dumped is not expanded initially.
Then I add another element to the array. Again print the same array.
Now when I expand both the first one shows the two elements inside when at the time of printing there was only one. Also the length, preview (unexpanded array) is inconsistent with what we see in the expanded view.

I am using Chrome Version 24.0.1312.27 beta.