[Webkit-unassigned] [Bug 242248] [WPE][GTK] 'Stop' button does not STOP

[bugzilla-daemon at webkit.org]

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

--- Comment #12 from Michael Catanzaro <mcatanzaro at redhat.com> ---
I naively attempted this:

diff --git a/Source/WebCore/loader/FrameLoader.cpp b/Source/WebCore/loader/FrameLoader.cpp
index 61c2a2e235a0..cff229c32dfa 100644
--- a/Source/WebCore/loader/FrameLoader.cpp
+++ b/Source/WebCore/loader/FrameLoader.cpp
@@ -2714,11 +2714,6 @@ void FrameLoader::checkLoadCompleteForThisFrame(LoadWillContinueInAnotherProcess
 {
     ASSERT(m_client->hasWebView());

-    // FIXME: Should this check be done in checkLoadComplete instead of here?
-    // FIXME: Why does this one check need to be repeated here, and not the many others from checkCompleted?
-    if (m_frame->document()->isDelayingLoadEvent())
-        return;
-
     switch (m_state) {
     case FrameState::Provisional: {
         // FIXME: Prohibiting any provisional load failures from being sent to clients
@@ -2732,6 +2727,11 @@ void FrameLoader::checkLoadCompleteForThisFrame(LoadWillContinueInAnotherProcess
         if (!provisionalDocumentLoader)
             return;

+        // FIXME: Should this check be done in checkLoadComplete instead of here?
+        // FIXME: Why does this one check need to be repeated here, and not the many others from checkCompleted?
+        if (m_frame->document()->isDelayingLoadEvent() && !m_provisionalDocumentLoader->isStopping())
+            return;
+
         // If we've received any errors we may be stuck in the provisional state and actually complete.
         auto& error = provisionalDocumentLoader->mainDocumentError();
         if (error.isNull())
@@ -2790,6 +2790,11 @@ void FrameLoader::checkLoadCompleteForThisFrame(LoadWillContinueInAnotherProcess
         if (m_documentLoader->isLoadingInAPISense() && !m_documentLoader->isStopping() && !m_checkingLoadCompleteForDetachment)
             return;

+        // FIXME: Should this check be done in checkLoadComplete instead of here?
+        // FIXME: Why does this one check need to be repeated here, and not the many others from checkCompleted?
+        if (m_frame->document()->isDelayingLoadEvent() && !m_documentLoader->isStopping())
+            return;
+
         setState(FrameState::Complete);

         // FIXME: Is this subsequent work important if we already navigated away?


Unfortunately, removing the isDelayingLoadEvent check from the top of FrameLoader::checkLoadCompleteForThisFrame causes the RELEASE_ASSERT(presentationSize) in VideoFrameGStreamer::createWrappedSample to fail. Not sure why.

-- 
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/20240605/3123c358/attachment.htm>