1904859 - Wait for events dispatched in the content process and assess performance

Status: NEW

(Remote Protocol :: Agent, task, P3)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

To rule out race conditions when dispatching events from an action chain, especially when multiple actions run in parallel within a tick, we need to ensure that the required events are indeed dispatched. Event listeners must be installed in the content process to wait for the events to be processed by the browser and the related events to be emitted before returning to the parent process for further processing of the action chain.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Further we should try to minimize the performance degradation caused by the additional step of waiting for the event to be dispatched. We should compare the results with Chrome's timings to ensure the impact is kept as low as possible.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This work will be needed once we emit widget events. With just processing actions in the parent process but still synthesizing events in the content process we basically have no change in how the events are dispatched. Because we do not wait for the event to be dispatched now, we won't need it immediately.

With bug 1922077 we will release the first chunk of work to our users. As such lets move this bug into M14.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I actually need some widget events implemented first before I can see how this will work. As such lets block on bug 1848957 which will implement the first widget event (wheel scroll).

Also not sure if it's immediately necessary so I'm going to set it as P3 for M14 and if I don't get to it lets prioritize as P2 again in the next milestone.