With bug 1694143 we will get basic support for log.entryAdded that just covers basic string messages. For a complete WebDriver BiDi support we still need the following features:

• Full support for ConsoleLogEntry (bug 1731543)
• Support for JavascriptLogEntry (bug 1731548)
• Automatically subscribe for newly created browsing contexts for globally registered events (bug 1731556)
• Cleanup internal event subscription states for closed browsing contexts (bug 1731565)
• Handling more data types in log messages by serializing complex objects (bug 1731589)
• Support for handling the stack property (bug 1731553)
• Emit cached log events when subscribing to log events (bug 1731574)

Most likely we want to split this bug into several individual ones due to its complexity.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #0)

With bug 1694143 we will get basic support for log.entryAdded that just covers basic string messages. For a complete WebDriver BiDi support we still need the following features:
...

The basic implementation focused on a subset of ConsoleLogEntry. In the specs we have three types of entries: GenericLogEntry, ConsoleLogEntry, JavascriptLogEntry.

ConsoleLogEntry is about everything that comes from the console API, and of we need to complete the implementation of this. I imagine JavascriptLogEntry is only about JS errors? So we can probably have a separate bug to support JS errors, it will require listening to different APIs anyway.

Are we considering other types of messages at the moment, and is there any plan to use GenericLogEntry?

For reference, in DevTools we have two other types of console messages:

• CSS messages, which are messages about the CSS usage of the page, but which are really FF specific and are probably not going to be useful from a test automation standpoint (could be useful for debugging tools later on though)
• Platform messages, which are coming from Services.console usage, and in DevTools are only surfaced in the Browser Toolbox / Browser Console. Probably irrelevant for test automation as well, would only be relevant to close the gap with DevTools

I'll split up this bug to several individual bugs.

(In reply to Julian Descottes [:jdescottes] from comment #2)

ConsoleLogEntry is about everything that comes from the console API, and of we need to complete the implementation of this. I imagine

I filed bug 1731543 for that.

JavascriptLogEntry is only about JS errors? So we can probably have a separate bug to support JS errors, it will require listening to different APIs anyway.

There is bug 1731548 now.

Are we considering other types of messages at the moment, and is there any plan to use GenericLogEntry?

For reference, in DevTools we have two other types of console messages:

• CSS messages, which are messages about the CSS usage of the page, but which are really FF specific and are probably not going to be useful from a test automation standpoint (could be useful for debugging tools later on though)
• Platform messages, which are coming from Services.console usage, and in DevTools are only surfaced in the Browser Toolbox / Browser Console. Probably irrelevant for test automation as well, would only be relevant to close the gap with DevTools

There are no other types as far as I can see in the spec, and I'm not sure what GenericLogEntry will cover. James, could you give some feedback? Maybe they cover parts of the above two types Julian mentioned?

Note that I transfer this bug over to a meta bug now so that we can have a better point estimation.

James, mind having a look at comment 4? Thanks.

At the moment the spec only covers console.log and JS errors. But that was more like an MVP of logging support; I'd expect us to add support for more things we log in devtools. Those extra things might need seperate spec proposals/discussions however, since not all browsers will have exactly the same set of things that generate warnings etc.

I don't see a need to keep this meta bug open. Lets dupe to the general log.entryAdded meta bug.