Store event region on non-composited frames

• Component: UI Events
• Status: NEW ---

[Daniel Bates]

I pushed the current design of event region past its limit in bug #210041 and this revealed bug #210278: updating event region for non-composited frames requires that the non-composited had layed out beforehand. The current design has compositing layers track and update an event region. Bug #210041 amended this design to have non-composited frames ask its enclosing compositing layer to do an event region paint that dives into (i.e. RenderWidget::paint() no longer bails out) the child that scheduled it. This opens up a situation where a compositing layer could try to dive into a child frame's content that didn't ask for an event region update as part of updating the composting layer's event region. I worked around this in bug #210278 with an added needsLayout() check in RenderWidget::paint(). The purpose of this bug is to remove that workaround.

[Radar WebKit Bug Importer]

<rdar://problem/61548751>

[Daniel Bates]

Note that we cannot depend on checking RenderView::needsEventRegionUpdateForNonCompositedFrame() in RenderWidget::paint() since it could be have been set by a deep nested non-composited child frame and an intermediary child frame along the path may have had its layout dirtied. That is why we check needsLayout(). Eventually the needsEventRegionUpdateForNonCompositedFrame() bit will be serviced (and turned off) once all frames along the path to the originally requesting frame lay out.

[Simon Fraser (smfr)]

Or figure out how to composite frames without a massive memory regression.