276312 2024-07-08 06:04:29 -0700 [WPE][GTK] Internal error fired from WebLoaderStrategy.cpp(559) : internallyFailedLoadTimerFired 2026-04-10 01:28:35 -0700 1 1 1 Unclassified WebKit WebKitGTK Other PC Linux RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=303704 P2 Normal --- 1 mcatanzaro spena aperez berto bugs-noreply mcatanzaro mcrha paul spena zimmermann oldest_to_newest 2045061 0 mcatanzaro 2024-07-08 06:04:29 -0700 In 278778@main I added logging to catch where frequent network errors in GTK port are coming from. Turns out 100% of our "internal errors" are coming from internallyFailedLoadTimerFired in WebLoaderStrategy.cpp: ERROR: WebKit encountered an internal error. This is a WebKit bug. /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp(559) : internallyFailedLoadTimerFired Unfortunately I do not have a reliable reproducer, and the website this occurs most frequently on is internal to Red Hat. That's going to make debugging difficult. But there are three reasons for such an error: * Network process crash (not happening in this case) * WebLoaderStrategy::scheduleLoadFromNetworkProcess called with no sourceOrigin (*probably* not?) * Messages::NetworkConnectionToWebProcess::ScheduleResourceLoad returns an error code (probably this?) I don't see how NetworkConnectionToWebProcess::ScheduleResourceLoad could fail, though. Not sure how to make further progress on this without a good reproducer. 2100372 1 mcatanzaro 2025-03-04 13:07:41 -0800 I see this same error message mentioned in bug #286834, but that is supposed to be fixed in 289567@main, and I just hit this today on YouTube using 290567@main which is newer, so there must be multiple bugs that trigger this error message. 2149164 2 mcatanzaro 2025-10-07 11:25:22 -0700 *** Bug 300321 has been marked as a duplicate of this bug. *** 2161818 3 berto 2025-11-28 06:32:58 -0800 I can reproduce this problem very easily with WebKitGTK 2.50.2 using Epiphany 48.5 in application mode to open Discord: $ /usr/bin/epiphany --application-mode --profile=$HOME/.local/share/org.gnome.Epiphany.WebApp_HASH https://discord.com/channels/... ERROR: WebKit encountered an internal error. This is a WebKit bug. Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp(618) : void WebKit::WebLoaderStrategy::internallyFailedLoadTimerFired() ERROR: WebKit encountered an internal error. This is a WebKit bug. Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp(618) : void WebKit::WebLoaderStrategy::internallyFailedLoadTimerFired() ERROR: WebKit encountered an internal error. This is a WebKit bug. Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp(618) : void WebKit::WebLoaderStrategy::internallyFailedLoadTimerFired() Removing the cache directory solves the problem: $ rm -rf ~/.cache/org.gnome.Epiphany.WebApp_HASH/ $ /usr/bin/epiphany --application-mode --profile=$HOME/.local/share/org.gnome.Epiphany.WebApp_HASH https://discord.com/channels/... 2162533 4 berto 2025-12-02 06:23:50 -0800 The problem also happens with WebKitGTK 2.50.1 2166339 5 zimmermann 2025-12-16 13:24:24 -0800 Also seen on the bots: https://build.webkit.org/results/GTK-Linux-64-bit-Debug-Tests/304475@main%20(17735)/http/tests/webrtc/filtering-ice-candidate-same-origin-frame2-crash-log.txt 2169632 6 mcatanzaro 2026-01-06 09:10:19 -0800 (In reply to Nikolas Zimmermann from comment #5) > Also seen on the bots: > https://build.webkit.org/results/GTK-Linux-64-bit-Debug-Tests/ > 304475@main%20(17735)/http/tests/webrtc/filtering-ice-candidate-same-origin- > frame2-crash-log.txt That log shows a use after free of SoupSession in the (unsandboxed!) network process. I'd say we have much bigger problems there than this loader issue. That's worth a separate security component bug report. 2182398 7 spena 2026-02-17 09:15:26 -0800 I won't claim it's an exact duplicate of https://bugs.webkit.org/show_bug.cgi?id=308051, but could you retest with the fix and see if it has solved these issues? 2182417 8 mcatanzaro 2026-02-17 09:59:13 -0800 Not worth testing, because this bug report predates the existence of NetworkMDNSRegisterGLib. :) 2182657 9 mcrha 2026-02-18 04:50:09 -0800 webkit2gtk4.1-2.50.4: > ERROR: WebKit encountered an internal error. This is a WebKit bug. > /builddir/build/BUILD/webkitgtk-2.50.4-build/webkitgtk-2.50.4/Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp(618) : void WebKit::WebLoaderStrategy::internallyFailedLoadTimerFired() I won't say it's a bug, at least not "internal error", because I closed a window which contained a WebKitWebView while it had been loading its content. The app itself had been still running, the window was not the app window. 2182691 10 mcatanzaro 2026-02-18 08:17:44 -0800 Ah, that explains a lot. In that case, probably the solution will be to just not print the error. Of course, we do still want to print the error when the load failure is expected. But load failure because the web view is destroyed is expected and not something we should be printing. 2182692 11 mcatanzaro 2026-02-18 08:18:15 -0800 > Of course, we do still want to print the error when the load failure is expected. I meant: we do still want to print the error when the load failure is unexpected. 2191657 12 paul 2026-03-19 02:45:01 -0700 We've also been hit by #300321 since Debian updated from 2.48.6 to 2.50.1 and been unable to render Salesforce dashboards properly since. The original post dismisses a network process crash, but I saw that its PID had been changing. On strace-ing it, I found that it does get SIGKILL-ed by something? Once the loading/rendering of the dashboard runs into the internal error while loading its resources, it will never render the page again until we nuke the cache. It feels like the cache gets corrupted somehow? Even if we "refresh" the page by either destroying the web view and reconstructing it again or loading the original dashboard URL, and that does not help. Finally, when using the Document Viewer cache model, the dashboard loads and renders properly again, albeit in a much slower fashion. Is there a way to find out what happens to the network process or cache here? 2191663 13 berto 2026-03-19 03:04:54 -0700 FWIW I can no longer reproduce this crash, same computer, same website, similar conditions (well, I'm on WebKitGTK 2.50.4 now, but from what I read other people are having problems with that release). I'm also on a different Debian point release, although I don't think that fixed anything. 2191672 14 paul 2026-03-19 03:25:51 -0700 I should have been more clear about the versions we use: We can still reproduce it with 2.50.4 (which is the version that Debian 13.4 (Trixie) has), but we haven't tested 2.50.6 yet as we await its backport. Interestingly, we cannot reproduce it in Epiphany 48.5 by closing and unclosing the tab (which I assume is similar behaviour to how are application does the refreshing). For the moment we are stuck with the WebKitGtk version 2.48.5 on Debian 12.13 (Bookworm) 2191678 15 berto 2026-03-19 03:47:00 -0700 > we haven't tested 2.50.6 yet as we await its backport. What a coincidence! :-) https://people.debian.org/~berto/webkit2gtk-2.50.6-1/ I plan to make the official releases today or tomorrow, but unless I find unexpected surprises during testing, they're going to be identical to those ones 2191703 16 paul 2026-03-19 05:11:52 -0700 Thanks for the heads up and your efforts! I tried those out, and it went immediately wrong on the first page "refresh". I guess we'll move ahead and upgrade to Debian Trixie with the cache model set to Document Viewer for now, accept the sluggish page loads and keep looking into why this happens. 2191719 17 mcatanzaro 2026-03-19 07:02:03 -0700 Do you have a URL that can be used to reproduce? 2191724 18 paul 2026-03-19 07:34:26 -0700 Unfortunately, I cannot share it, because it is a company's internal job hiring dashboard :( And we mainly have issues with these Salesforce dashboards. I had put my hope into the issue also existing for Discord and the Tauri app of #300321. I will be on the lookout for some public! 2191725 19 berto 2026-03-19 07:47:51 -0700 So it happens in both bookworm and trixie, is that correct? If you manage to get a stack trace of the error that would be helpful. 2191726 20 mcatanzaro 2026-03-19 08:03:44 -0700 A stack trace is not possible without a core dump. OK, reviewing this issue report again, I think you're hitting this problem as a *side effect* of your network process dying, because it's expected that this error message should be printed in that case. You mentioned it was receiving SIGKILL, which is very weird. I think you need a separate bug report. (Could it be OOM killer, like systemd-oomd?) 2194484 21 spena 2026-03-27 14:45:36 -0700 Pull request: https://github.com/WebKit/WebKit/pull/61528 2198722 22 ews-feeder 2026-04-10 01:28:31 -0700 Committed 310907@main (0831c81f23e3): <https://commits.webkit.org/310907@main> Reviewed commits have been landed. Closing PR #61528 and removing active labels.