Use WebKit::blockedError instead of ResourceLoader::blockedError in WebLoaderStrategy::scheduleLoadFromNetworkProcess
Created attachment 457288 [details] Patch
<rdar://problem/91295875>
Comment on attachment 457288 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=457288&action=review > Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:329 > + RunLoop::main().dispatch([resourceLoader = Ref { resourceLoader }, request] { May have been easier to capture `resourceLoader->blockedError()` in the lambda and it would have been more obvious that the new code is identical in behavior to the previous one.
Comment on attachment 457288 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=457288&action=review >> Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:329 >> + RunLoop::main().dispatch([resourceLoader = Ref { resourceLoader }, request] { > > May have been easier to capture `resourceLoader->blockedError()` in the lambda and it would have been more obvious that the new code is identical in behavior to the previous one. This copies the ResourceRequest. Is that necessary?
Comment on attachment 457288 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=457288&action=review >>> Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:329 >>> + RunLoop::main().dispatch([resourceLoader = Ref { resourceLoader }, request] { >> >> May have been easier to capture `resourceLoader->blockedError()` in the lambda and it would have been more obvious that the new code is identical in behavior to the previous one. > > This copies the ResourceRequest. Is that necessary? With my proposal, we would effectively just "move" a ResourceError in, which seems better.
I like just capturing the error. This is the same behavior without the possibility of null dereferencing because WebFrameLoaderClient::blockedError just calls WebKit::blockedError.
Created attachment 457293 [details] Patch
Committed r292738 (249522@main): <https://commits.webkit.org/249522@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 457293 [details].