Null check provisionalItem in FrameLoader::continueLoadAfterNavigationPolicy
Created attachment 373135 [details] Patch
<rdar://problem/48262384>
Comment on attachment 373135 [details] Patch So, I’ve been out of this code for a while. But I spent like ***20**** seconds just grepping this file for provisionalItem and I can say that this patch makes absolutely no sense to me. Hint: It contradicts a bunch of RELEASE_ASSERTS. And with 0 details about why this fix is necessary except an appeal to “Let’s not crash” I have no means of helping you further (I don’t have a radar client handy at the moment).
This is an attempt to fix a top crash based on telemetry. It doesn't contradict a RELEASE_ASSERT in the control flow path that led to the crash, because otherwise these crashes would have crashed earlier. The crash is known to be a null Derek on this line. So this is probably sensible as a speculative fix, even though there's probably something deeper wrong here.
(In reply to Daniel Bates from comment #3) > Comment on attachment 373135 [details] > Patch > > So, I’ve been out of this code for a while. But I spent like ***20**** > seconds just grepping this file for provisionalItem and I can say that this > patch makes absolutely no sense to me. Hint: It contradicts a bunch of > RELEASE_ASSERTS. And with 0 details about why this fix is necessary except > an appeal to “Let’s not crash” I have no means of helping you further (I > don’t have a radar client handy at the moment). That is true but we've been trying to fix this particular crash for the last 2-3 releases and at some point, we need to fix the damn crash for the sake of our users instead of keep investigating what the root cause is.
Comment on attachment 373135 [details] Patch Clearing flags on attachment: 373135 Committed r247021: <https://trac.webkit.org/changeset/247021>
All reviewed patches have been landed. Closing bug.