1 files changed, 28 insertions, 1 deletions

diff --git a/app/src/main/java/org/terst/feedreader/readability/ReaderExtractor.kt b/app/src/main/java/org/terst/feedreader/readability/ReaderExtractor.kt
index 9be08b0..286588a 100644
--- a/app/src/main/java/org/terst/feedreader/readability/ReaderExtractor.kt
+++ b/app/src/main/java/org/terst/feedreader/readability/ReaderExtractor.kt
@@ -2,6 +2,8 @@ package org.terst.feedreader.readability
 
 import android.annotation.SuppressLint
 import android.content.Context
+import android.os.Handler
+import android.os.Looper
 import android.webkit.WebView
 import android.webkit.WebViewClient
 import kotlinx.coroutines.Dispatchers
@@ -46,7 +48,16 @@ object ReaderExtractor {
             val webView = WebView(context)
             webView.settings.javaScriptEnabled = true
 
+            // A slow-loading page's evaluateJavascript callback can arrive right as the
+            // outer withTimeoutOrNull cancels this coroutine, racing finish() (JS-callback
+            // path) against invokeOnCancellation (timeout path). Both used to call
+            // webView.destroy() unconditionally -- a double destroy() crashes natively.
+            // This flag makes teardown happen exactly once no matter which path wins.
+            var finished = false
+
             fun finish(result: ExtractedArticle?) {
+                if (finished) return
+                finished = true
                 if (continuation.isActive) continuation.resume(result)
                 webView.stopLoading()
                 webView.destroy()
@@ -89,7 +100,23 @@ object ReaderExtractor {
                 }
             }
 
-            continuation.invokeOnCancellation { webView.destroy() }
+            // withTimeoutOrNull's cancellation is driven by a delayed task on
+            // kotlinx.coroutines.DefaultExecutor, NOT the calling coroutine's dispatcher --
+            // so this handler can run on a background thread despite the whole extraction
+            // being wrapped in withContext(Dispatchers.Main). Touching the WebView there
+            // crashes ("A WebView method was called on thread ..."), which is exactly what
+            // a slow/never-finishing article load (timing out after TIMEOUT_MS) hit every
+            // time -- reproduced here as the real "crash loop" root cause. Hop back to the
+            // main looper before tearing down.
+            continuation.invokeOnCancellation {
+                Handler(Looper.getMainLooper()).post {
+                    if (!finished) {
+                        finished = true
+                        webView.stopLoading()
+                        webView.destroy()
+                    }
+                }
+            }
             webView.loadUrl(url)
         }
 }