WIP for console.group

[jasonLaster]

No description provided.

[bvaughn]

"groupCollapsed" ? 😁

😮 "table" ???

[jasonLaster]

good call. Here are more log levels from firefox
https://searchfox.org/mozilla-central/source/toolkit/modules/Console.jsm#285-304
https://searchfox.org/mozilla-central/source/devtools/client/webconsole/utils/messages.js#563-583

[loganfsmyth]

I had mentioned this in chat, but I'll note here that this is insufficient to capture the semantics of grouping, because we discard console messages sometimes, and grouping explicitly relies on opening and closing messages, so this on its own will easily cause the nesting of group/End messages to become mismatched, so this patch passes along grouping info, but then introduces a separate problem.

[jasonLaster]

Good call

[bvaughn]

RE: Nesting:

I think it's probably reasonable to pass the potentially unmatched groups to the frontend and rely on it to do a smart thing (like ignoring group-close entries without group-opens, or auto-closing unclosed groups).

[bvaughn]

It's a little unclear to me if you are describing a case/scenario that I didn't list above?

[loganfsmyth]

Fair, should have been clearer. It seems like the randomness of recordings and of recording region division mean that any particular log statement may end up falling into your "Ambiguous" item.

What I'm trying to illustrate with my examples is that I don't think we can fix the ambiguous cases, and I'm realizing a detail that I should have clarified, which is that the linker itself is what tracks overflow, so when there are overflowing messages, we literally know nothing, even in the backend, about those messages, for

We could consider having the backend always append any group/groupCollapsed entries to the start of a log chunk so that we can avoid scenarios 2 and 3 above, but I don't know how messy that might be on the backend. Also happy to talk about alternate approaches!

We do not have enough information in the backend to know how to do this for the ambiguous case, because we would need to know when groups may have been opened or closed in the overflowed messages.

So either the messages themselves need to know their depth, or the linker itself needs to track message depth for overflowing messages, even if it discards the message itself.

[bvaughn]

Gotcha. Thank you for distilling that.

So either the messages themselves need to know their depth

I'm not sure what this means. Are you saying that the gecko/chromium/node would have to store this information at runtime/record-time?

I have no idea how much effort that would be. If it's easy to do, then– that would be a great option to have.

I think we might still be skipping past what the desired behavior is for the scenarios I raised above. Like maybe the thread moved forward under the assumption that preserving the indentation was definitely what we wanted to do– but I'm not sure it is.

For instance, what Chrome does when you clear the console feels somewhat analogous to how our focus window feature works? In this case, Chrome blows away the indentation:

[loganfsmyth]

For instance, what Chrome does when you clear the console feels somewhat analogous to how our focus window feature works? In this case, Chrome blows away the indentation:

That's fair, I guess the core of what I want is to ensure that overflow doesn't cause us to lose information about group nesting, so I want to make sure that information comes through somewhere, so then the question is what should that information look like to get what we want. In your example above I'd think like:

console.group("group"); // depth 0
// Focus window starts here
console.log("foo1"); // depth 1
console.groupEnd();
console.log("foo2"); // depth 0
console.group("group2");
console.log("foo3"); // depth 1
console.groupEnd();
// Focus window ends here

I think I'd expect that either the frontend would indent foo1 to depth 1, or else it could choose to adjust the depths by recognizing that the first groupEnd didn't have a start, and would basically decide to ignore that groupEnd and adjust the depths of all the messages before the first groupEnd.

[bvaughn]

The frontend could detect and handle indentation for the scenario you've described– since the presence of a groupEnd implies a group (or groupCollapsed– although this is kind of an interesting distinction TBH). What should the frontend do in this case:

console.groupCollapsed("Header text");
// Focus window starts here
console.log("This log should be hidden by default");
console.groupEnd();
// Focus window ends here

We can infer that there was a group but don't know that it was collapsed– and even if we could there would be nothing to show as the toggle header. (We wouldn't have the "Header text" string.)