As each ViewBackend (and hence web view) can get its contents rendered
by different WPEWebProcess due to PSON, keep around a list of all the
differen bridgeIds which have been associated with it in a std::vector.
Newly added elements are always pushed at the back, so the most recent
association (i.e. the "current" active one) is always the last element.
Keeping the list allows getting back to the previously used ones.

Arrange for calling ViewBackend::unregisterSurface() also when a Surface
is destroyed. This is a no-op if the nested compositor had the chance
to receive and handle a FdoIPC::UnregisterSurface message before the
surface is destroyed; but allows undoing the bridge association when the
Wayland client connection is closed beforehand. The destruction callback
for the surface is guaranteed to always be called by libwayland, even
on dropped connections, to allow cleaning up reagardless of the fate
of its clients.

Among others, this covers the case in which a WPEWebProcess is abruptly
exited, for example due to a crash or a top-level resource load being
blocked by a content filter.

Co-authored-by: Adrian Perez de Castro <[email protected]>
Acked-by: Adrian Perez de Castro <[email protected]>
Signed-off-by: Pablo Saavedra <[email protected]>

…urface

In an un/register surface action is taken; make sure that surfaces other than
the new active one do not have callbacks pending to be dispatched.

Co-authored-by: Adrian Perez de Castro <[email protected]>
Acked-by: Adrian Perez de Castro <[email protected]>
Signed-off-by: Pablo Saavedra <[email protected]>

The ~ViewBackend sets now the m_backend to NULL and the
ViewBackend::dispatchFrameCallbacks() checks if m_backend is not NULL
before call wpe_view_backend_dispatch_frame_displayed().

Acked-by: Adrian Perez de Castro <[email protected]>
Signed-off-by: Pablo Saavedra <[email protected]>

This patch address the following scenario:

* View 1: Opens a non-blocked page (surface1) (domain1/pageA)
* View 1: Opens a blocked page (surface2) (domain2/pageA)
  * That add a new bridge Id in the bridgeIds
  * Frames related to the surface1 arrives late (after the new surface is
    registered). There is not a dispatch notification because the
    `bridgeIds.back()`, at that moment, is associated to the `surface2`.
    Therefore `wpe_view_backend_dispatch_frame_displayed(m_backend);` is
    inhibited
  * Destroy surface2 because the content is filtered
* View 2: Opens a non-blocked page (surface3) (domain3/pageC)
* View 2: Closed
  * Destroy ViewBackend
  * Destroy Surface3
* View 1: Open a non-blocked page in the same domain that the related to
  the surface1 (domain1/pageB)

* Issue: New frames will not be generated because the previous
  `wpe_view_backend_dispatch_frame_displayed` was not called for related
  WebProcess backend (1)

Signed-off-by: Pablo Saavedra <[email protected]>

... instead of do it throught the ViewBackend::unregisterSurface().

During destruction we only want to remove the surface-viewbackend
association but we do not want to call dispatchFrameCallbacks because
the nested compositor client is dying

Acked-by: Pablo Saavedra <[email protected]>