1713440 - MessageHandler: Support chrome browsing contexts

Status: REOPENED

(Remote Protocol :: WebDriver BiDi, task, P3)

Description

[Julian Descottes [:jdescottes]]

Add support for chrome window contexts. This is currently not handled in the prototype stack.

Even for such parent process contexts, a dedicated CommandsHandler should be created for the target chrome window context.
We might reuse the same transport class as the one created for Bug 1713439 or come up with a dedicated one.

Comment 1

[Julian Descottes [:jdescottes]]

As a proof of concept based on the current MessageHandler patches, the following patch allows to capture log events emitted from a chrome window.

https://hg.mozilla.org/try/rev/8d985698a779b2bebcd8fc042be13b37c87a8b7d

It does two things:

• relaxes the filtering performed in the FrameTransport in order to also accept parent process browsing contexts
• adds the includeChrome flag to the MessageHandlerFrameActor definition

With this, the following manual test should work:

• start firefox with --remote-debugging-port
• direct connect to BiDi with a websocket client
• create a session
• send a session.subscribe command for ['log.entryAdded']
• open the BrowserToolbox
• run gBrowser.ownerGlobal.console.log("TEST") (gBrowser.ownerGlobal points to the Chrome window)
• you should receive an entryAdded event

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

Resetting points for now given that I don't think that this should really be 8 points.

I just found this bug and we probably should have it separated out from any implementation bug of a BiDi command supporting the parent process.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

As discussed in the triage meeting today this is a very old bug and it might not apply anymore, or would have to be split anyway. We decided to close it.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

This is actually not a wontfix. We still have to add support for chrome contexts to the message manager. At least it is necessary for retrieving all the supported browsing contexts - right now only tab related browsing contexts are queried for. This is going to block support for realm targets when evaluating scripts via script.evaluate and script.callFunction.

Overall we need to pass along the request to include and filter as well chrome browsing contexts down until isBrowsingContextCompatible. This requires a bit of refactoring.

(In reply to Julian Descottes [:jdescottes] (PTO -> Jan 5th) from comment #1)

• adds the includeChrome flag to the MessageHandlerFrameActor definition

Adding this flag is now getting done on bug 1944570 with the implementation of the script.evaluate and script.callFunction commands by using a chrome browsing context.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

I had to disable the test remote/shared/messagehandler/test/browser/browser_session_data_browser_element.js temporarily because browser chrome tests always run with system access allowed and this would mean that we include chrome and not only browser windows, so the test starts to fail because the session data is as well loaded into extension sidebars. We need to reenable the test with the patch on this bug.