The case for expandable arrays is clearer than the case for functions.  While being able to click to expand function objects would allow easier introspection, clicking is also used to jump to the function definition.  We should introduce an expandable arrow if it doesn't take away the benefit of clicking to jump to definition.

Deleted: functionexpandables.png 12.8 KB

	functionexpandables.png 12.8 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/697a783fb10a4ec2777c71d22521820856816a91

commit 697a783fb10a4ec2777c71d22521820856816a91
Author: luoe <luoe@chromium.org>
Date: Fri Jul 08 21:47:50 2016

DevTools: make arrays expandable by default in console

BUG= 607682 

Review-Url: https://codereview.chromium.org/2120613002
Cr-Commit-Position: refs/heads/master@{#404499}

[modify] https://crrev.com/697a783fb10a4ec2777c71d22521820856816a91/third_party/WebKit/LayoutTests/inspector/console/console-external-array-expected.txt
[modify] https://crrev.com/697a783fb10a4ec2777c71d22521820856816a91/third_party/WebKit/LayoutTests/inspector/console/console-external-array.html
[modify] https://crrev.com/697a783fb10a4ec2777c71d22521820856816a91/third_party/WebKit/LayoutTests/inspector/console/console-format-broken-unicode.html
[modify] https://crrev.com/697a783fb10a4ec2777c71d22521820856816a91/third_party/WebKit/LayoutTests/inspector/console/console-format-expected.txt
[modify] https://crrev.com/697a783fb10a4ec2777c71d22521820856816a91/third_party/WebKit/Source/devtools/front_end/console/ConsoleViewMessage.js

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865

commit e3bc1d8cebf65a51bb23abf204cf1ba059f1e865
Author: luoe <luoe@chromium.org>
Date: Fri Aug 05 17:43:28 2016

DevTools: show alternate title onexpand of object in console

Results logged in the console with an expandable arrow will show a full preview
title when collapsed and a description when expanded. For example, an array
"[1, 2, 3]" might expand into "Array[3]".

BUG= 607682 

Review-Url: https://codereview.chromium.org/2139043002
Cr-Commit-Position: refs/heads/master@{#410100}

[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-call-getter-on-proto-expected.txt
[add] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-edit-property-value-expected.txt
[add] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-edit-property-value.html
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-format-array-prototype.html
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-format-broken-unicode.html
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-format-es6-2-expected.txt
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-format-es6-2.html
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-format-es6-expected.txt
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-format-es6.html
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-format-expected.txt
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-format.html
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-log-object-with-getter-expected.txt
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-object-preview-expected.txt
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-object-preview.html
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-proxy-expected.txt
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-proxy.html
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/console-uncaught-promise-expected.txt
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/LayoutTests/inspector/console/worker-eval-contains-stack-expected.txt
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/Source/devtools/front_end/components/ObjectPropertiesSection.js
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/Source/devtools/front_end/console/ConsoleViewMessage.js
[modify] https://crrev.com/e3bc1d8cebf65a51bb23abf204cf1ba059f1e865/third_party/WebKit/Source/devtools/front_end/console/consoleView.css

There's currently 3 ways arrays are formatted.  In the last case, console.dirxml() can still make these weird layouts where an array entry is expandable.

For dirxml, we can make its behavior identical to today's ConsoleCommandResult formatting (uses XML for objects but not array entries).

Deleted: 3arrayFormatExpand.png 23.3 KB

	3arrayFormatExpand.png 23.3 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/144fcc80829114973858a506aa38633bf63ef6d7

commit 144fcc80829114973858a506aa38633bf63ef6d7
Author: luoe <luoe@chromium.org>
Date: Thu Sep 29 01:46:39 2016

DevTools: console.dirxml() stops using XML format for array entries

Using console.dirxml() on an array of elements will no longer use XML formatting
for the array entries when collapsed. E.g. "[<span>...</span>]" >> "[span]".
This is identical to the formatting used today for evaluated results in console.

BUG= 607682 

Review-Url: https://codereview.chromium.org/2378183002
Cr-Commit-Position: refs/heads/master@{#421709}

[modify] https://crrev.com/144fcc80829114973858a506aa38633bf63ef6d7/third_party/WebKit/LayoutTests/inspector/console/console-dirxml-expected.txt
[modify] https://crrev.com/144fcc80829114973858a506aa38633bf63ef6d7/third_party/WebKit/Source/devtools/front_end/console/ConsoleViewMessage.js

looks good!

Deleted: Screen Shot 2016-09-29 at 10.30.25 AM.png 18.0 KB

	Screen Shot 2016-09-29 at 10.30.25 AM.png 18.0 KB View Download

Deleted: Screen Shot 2016-09-29 at 10.30.31 AM.png 19.2 KB

	Screen Shot 2016-09-29 at 10.30.31 AM.png 19.2 KB View Download

This change has broken expansion of HTML elements.

Previously $$('body') array elements were expanded as HTML elements (DOM tree was shown).
Now $$('body') array elements are expanded as JavaScript objects (properties are shown).

In other words, this change did the entirely wrong thing because currently single HTML element expansion is performed in XML format, but JS object format is used when that element is inside an array. Er, where's the logic?

The correct resolution was to keep the XML format of a single HTML element when it's inside an array. Or to switch everything to JS object format. Anyway, the decision should be based on number of times console.dir was used on a HTML element instead of direct logging of the element.

Hello, thank you for letting us know your feedback.  I want to understand where you're coming from.  It sounds like this change removing the expandable XML format for array entry elements broke your workflow.  Can you please describe your use case and explain why it was better to have expansion arrows inside array entries?

The motivation to never format array entries with inline expandable arrows was to use a consistent format that avoided weird layouts.  For any array entry, allowing inline expansion arrows leads to hard-to-read layouts like the one in the screenshots.  There was no decision to make elements an exception, because doing so would break the purpose of making arrays more readable.

In the "$$('body')" case you provided, the result is a single expansion arrow "> [body]".  Clicking on the 'body' only expands the section, revealing it as a JS object.  This requires 2 clicks to see the body's DOM instead of 1 click before.  Would your workflow be improved if clicking on elements in a collapsed array directly sent you to its DOM the Elements Panel instead of expanding the array?  We could make a new bug to keep users only 1 click away from seeing an element's XML.

As you pointed out, it is not consistent to see elements formatted one way (XML when alone) and then another way (JS object when inside array).  There is actually another bug to address this by changing all elements' format to JS object that link to Elements Panel, except for dirxml():

crbug.com/607686

For now, elements are still expandable in the console, but I would really appreciate knowing how your workflow is changed and how it can be improved.

Reopened to extend this issue for other cases we missed:

Throwing an array/object in an error will also make for strange layouts.  Due to wrapping, this may have cases where the user clicks the arrow and the newly shown stack trace is not shown directly below the "Uncaught"

We can investigate taking the arrow off of the logged array/object after the "Uncaught" and instead have some "[[value]]" property inside the error that is visible when the entire thing is expanded.

> Uncaught [1,2,3]

"Click >"

V Uncaught [1,2,3]
   > Array[3]
   (func) @ file.js
   (func) @ file.js
   (func) @ file.js

#11: I fully concur with pfeldman in 607686#1: "Why would you ever want to expand dom wrapper as a JS object? It has a 1000 standard properties that carry no information at all."

I'm not sure what else there is to say. The switch to JS-object format seems to me a meaningless UI cosmetic that breaks the primary use of $$('selector'), $x('selector').

This also breaks another real world use case on millions of pages that define jQuery $ which returns a jQuery array - after this "fix" of "weird" layouts the elements are expanded as objects even for a single DOM element because it's inside a jQuery array.