(In reply to Andreas Tolfsen 「:ato」 from bug 1589782 comment #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.

Given that we have the basic implementation and none of those items from Andreas seem to affect the Gutenberg e2e tests negatively, I would suggest to pull this bug from the alpha release. If it turns out we need something specific, we will add the real implementation bug as blocker.

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

Given that we have the basic implementation and none of those
items from Andreas seem to affect the Gutenberg e2e tests
negatively, I would suggest to pull this bug from the alpha
release. If it turns out we need something specific, we will add
the real implementation bug as blocker.

Makes sense to me.

It’s a relief at least Gutenberg doesn’t rely on parsing log messages
to control the test suite flow.

No more work is needed.