[webkit-changes] [WebKit/WebKit] 7175cd: Deadlock under ~PluginView() with PDFPlugin.

[lericaa]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7175cd9a22b4a115e8fc413db3fb759b193b0b80
      https://github.com/WebKit/WebKit/commit/7175cd9a22b4a115e8fc413db3fb759b193b0b80
  Author: Erica Li <lerica at apple.com>
  Date:   2024-02-14 (Wed, 14 Feb 2024)

  Changed paths:
    A LayoutTests/compositing/plugins/pdf/pdf-plugin-hang-during-destruction-expected.txt
    A LayoutTests/compositing/plugins/pdf/pdf-plugin-hang-during-destruction.html
    M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h
    M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm
    M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h

  Log Message:
  -----------
  Deadlock under ~PluginView() with PDFPlugin.
rdar://108489643
https://bugs.webkit.org/show_bug.cgi?id=268536

Reviewed by Simon Fraser.

dataProviderGetBytesAtPosition might be invoked recursively from CG, and it highly increased the possiblity when the main runloop is destructing the PDFPlugin,
while the another main runloop is dispatched from dataProviderGetBytesAtPosition and does not get chance to signal semaphore as it is waiting current runloop to finish,
that causes deadlock. This change is to stop dispatch main runloop when plugin has been destroyed and signal the semaphore before main thread calling waitForCompletion for m_pdfThread.

* LayoutTests/compositing/plugins/pdf/pdf-plugin-hang-during-destruction-expected.txt: Added.
* LayoutTests/compositing/plugins/pdf/pdf-plugin-hang-during-destruction.html: Added.
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm:
(WebKit::PDFIncrementalLoader::clear):
(WebKit::PDFIncrementalLoader::dataProviderGetBytesAtPosition):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
(WebKit::PDFPluginBase::hasBeenDestroyed const):

Canonical link: https://commits.webkit.org/274694@main