https://chromedevtools.github.io/devtools-protocol/tot/Log#event-entryAdded

Example:

{"method":"Log.entryAdded","params":{"entry":{"source":"recommendation","level":"verbose","text":"[DOM] Input elements should have autocomplete attributes (suggested: \"current-password\"): (More info: https://goo.gl/9p2vKq) undefined","timestamp":1570753236522.156,"url":"http://localhost:8889/wp-login.php?loggedout=true&wp_lang=en_US","args":[{"type":"object","subtype":"node","className":"HTMLInputElement","description":"input#user_pass.input.password-input","objectId":"{\"injectedScriptId\":15,\"id\":1}"}]}}

Note that I already implemented Log.entryAdded in the original
remote agent prototype. It is emitted from here:
https://searchfox.org/mozilla-central/source/remote/domains/content/Log.jsm#62

It currently supports script errors, console messages, and console
API log events.

Some concerns about the existing implementation and a few unanswered
questions are:

• There’s no way of opting in to specific log types. It’s currently
  everything or nothing.

• It’s unclear whether Log.enable is meant to work for all browsing
  contexts or a specific browsing context. Maybe this depends on which
  is the target of the message.

• Gecko has different types of logs that don’t conform with Chrome’s.
  Some of them only produce events globally. Some only in content.

• Some of Gecko’s loggers have more log levels than Chrome, so we
  make a lossy reduction when we map them to CDP log levels.

• I suspect we will be seeing an alternative proposal for logging
  in WebDriver Bi-Di that is different to the CDP approach, but they
  may be able to reuse the same event prototype.

In any case I would propose we close/rework this bug and file
specific bugs related to the abovementioned known problems.

Whoops, sorry I missed that. I'll circle back to file more specific bugs later today.

We can re-open a more specific bug if we find that there's something about entryAdded that is blocking gutenberg.