[Webkit-unassigned] [Bug 209232] On PSON, WebPageProxy listens to two DrawAreaProxy at the same time

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=209232

--- Comment #3 from youenn fablet <youennf at gmail.com> ---
(In reply to Chris Dumez from comment #1)
> (In reply to youenn fablet from comment #0)
> > When PSONing, a web page proxy listens to two DrawingAreaProxy.
> > While this may not be an issue when everything is working and rendering is
> > properly suspended in WebProcess, this is fragile design, as shown by
> > regression in https://bugs.webkit.org/show_bug.cgi?id=208918.
> > 
> > It seems that, ideally, when the provisional DrawingAreaProxy starts
> > receiving some messages, WebPageProxy should stop listening to the old one.
> 
> This would not be right. While the provisional page exists, the WebPageProxy
> is still the one displayed on screen and interactive. It definitely should
> keep listening to IPC from its DrawingArea. At any point, the provisional
> load can be cancelled and it would be like nothing had happened.

Currently, both drawing areas are linked to the same WebPageProxy.
It they both receive EnterAcceleratedCompositingMode IPC messages roughly at the same time, they will call WebPageProxy:: enterAcceleratedCompositingMode and the last one will win. It would be nice to fix this.

There is nothing preventing a buggy or bad-behaving web process to send this IPC message and keep the control of what is being displayed on the supposed-to-be process-swapped tab.

It makes sense to me that the drawing areas would forward their messages to their WebPageProxy when they are set to WebPageProxy::m_drawingArea but not otherwise.
In the current design, that would probably require buffering some state.
I could check again but I believe enterAcceleratedCompositingMode messages are processed for the provisional drawing area before it is assigned to WebPageProxy::m_drawingArea.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200318/fdfc516e/attachment.htm>