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

[lericaa]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 89a06fec3aed7311462e7614afa571d3babf4aef
      https://github.com/WebKit/WebKit/commit/89a06fec3aed7311462e7614afa571d3babf4aef
  Author: Erica Li <lerica at apple.com>
  Date:   2024-02-02 (Fri, 02 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

  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 document finshed loading 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):

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