1510067 - [reporter] console.log objects are not very useful in their current form

Status: RESOLVED FIXED

(Web Compatibility :: Tooling & Investigations, enhancement, P1)

Description

[Karl Dubost💡 :karlcow]

When working on https://github.com/webcompat/webcompat.com/issues/2659
I discovered that the logs for objects were not very useful.

when devtools are reporting an object it creates a line giving the name of the object that we can expand in multiple sub-structures. 

Currently the reporter just sends back  [object Object]
which is not that useful. 

There will be a choice to make, because expanding all substructures can trigger quite a big (infinite? circular?) expansion. 


But we should probably improve what we currently have if possible.

Comment 1

[Ksenia Berezina [:ksenia]]

I've made changes for 1510073 and structured the payload in the proposed format:

{
        "level": "${level}",
        "log": "${args}",
        "uri": "${filename}",
        "pos": "${lineNumber}:${columNumber}"
}

Where log is being passed as a string as a moment.

For the current bug I'm planning on passing an object (if there is one) as log without stringifying it. However there is a possibility of multiple arguments with different types in one console.log, e.g. console.log('test', 'test1', {someprop: '1', anotherprop: '999'}); .

Currently they're being combined in one string:

evt.arguments.map(arg => {
        return "" + arg;
      }).join(", ");

So we can either pass an array of arguments in log, in this case the above example will be:

"log": ['test', 'test1', {someprop: '1', anotherprop: '999'}]

and one arg messages will be:

"log": ['test']

OR keep log as a string and add another property to the payload (objects that will be an array, possibly?). If there are any objects among arguments we'll add them to that array.

Karl, maybe you have some thoughts on that?

Comment 2

[Karl Dubost💡 :karlcow]

Ksenia,

That's a very good question.

For the current bug I'm planning on passing an object (if there is one) as log without stringifying it.

Yes I think that would be a good idea.

The master of console.log in devtools is Nicolas. And probably he has a better understanding on how the console.log is working. Specifically devtools are already processing and displaying the data. So I wonder if they have a specific format for dealing with these data. I discussed with Brian (Birtles) who explained to me that the messages didn't have a unique source and had different format depending on where they were coming from.

My own guts are telling me if we have a well defined structured format as a JSON object. We can happily parse it on the server side and/or client side to render it in the format of our choices.

Another option would be to do like images and basically uploading them as a json file on the server.
And then we would be free on the server/client side to insert a link which would either directly link to them and/or prettify them inserted in the bug report.

Comment 3

[Nicolas Chevobbe [:nchevobbe]]

Hello,

So I wonder if they have a specific format for dealing with these data.

Yes, due to devtools nature, the console doesn't have access to the direct logged data, so each object are turned into what we call a Grip, which is a serializable object describing the data.
You can see an example in devtools/client/webconsole/test/fixtures/stubs/consoleApi.js#2727-2789.
We are using what we call previewers to build those structure for all kind of js types devtools/server/actors/object/previewers.js .

On the client side, we then have a set of React component (called Reps) that we use to render these grips.

---

We also have stringifiers, which return a string for a given object (devtools/server/actors/object/stringifiers.js ), but I don't think we have the same coverage as in previewers.

---

I don't fully understand what you are trying to achieve, so if you have a detailed example I can reproduce I may suggest something that suits the situation better.

Comment 4

[Ksenia Berezina [:ksenia]]

Nicolas, thanks for providing the links.

We're trying to better format objects from console.log data that are being passed from an extension (report site issue) to webcompat.com via POST. At the moment all objects are being stringified, which is not useful, so we need to improve it.

We're using getEvents method of ConsoleAPIStorageService to get the list of all events:

https://searchfox.org/mozilla-central/source/browser/extensions/report-site-issue/experimentalAPIs/tabExtras.js#45

If an object was logged in a console, it is accessible through arguments property of an event, which works fine unless an object is huge or has a circular reference. So we need to find a way to deal with those kind of objects.

I've looked at the previewers and looks like we could do something similar or possibly reuse them. Having a preview of 10 properties of an object may be sufficient for our needs. Is there a way to use previewers from within an extension?

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

Ah, now I understand better.
I came across this in the past https://github.com/skerit/json-dry
Do you think you could use it to transform your object before posting it? Then on the other end, you could use it again to parse the posted data ?

Comment 6

[Ksenia Berezina [:ksenia]]

Thanks Nicolas, I'll try it out.

Comment 7

[Ksenia Berezina [:ksenia]]

Attachment: Bug 1510067 - change structure of console log messages reporting, create preview of objects and arrays

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3be2257eb121
change structure of console log messages reporting, create preview of objects and arrays r=twisniewski,Gijs

Comment 9

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/3be2257eb121