Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1603783002:
Add null check of the return value of Document::frame() in DTL::reportResponseReceived(). (Closed)
|
Created:
4 years, 11 months ago by horo Modified:
4 years, 11 months ago CC:
chromium-reviews, blink-reviews, loading-reviews_chromium.org, tyoshino+watch_chromium.org, Nate Chapin, gavinp+loader_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionAdd null check of the return value of Document::frame() in DTL::reportResponseReceived()
BUG=578849
Committed: https://crrev.com/d2535dca624b5531247dbcbc2048dded6e9c45fc
Cr-Commit-Position: refs/heads/master@{#370674}
Patch Set 1 #
Total comments: 3
Patch Set 2 : add comments and ASSERT #
Total comments: 2
Patch Set 3 : use TODO #Messages
Total messages: 20 (7 generated)
Description was changed from ========== Add null check of the return value of Document::frame() in DocumentThreadableLoader::reportResponseReceived() BUG=578849 ========== to ========== Add null check of the return value of Document::frame() in DTL::reportResponseReceived() BUG=578849 ==========
horo@chromium.org changed reviewers: + kinuko@chromium.org
Could you please review this?
https://codereview.chromium.org/1603783002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp (right): https://codereview.chromium.org/1603783002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:435: InspectorInstrumentation::didReceiveCORSRedirectResponse(document().frame(), resource->identifier(), document().frame()->loader().documentLoader(), redirectResponse, 0); We access document().frame() in a similar situation, do we have crashes for this one? Should we protect this too?
Could this happen when XML request is made in unload handler?
On 2016/01/19 13:48:54, kinuko wrote: > Could this happen when XML request is made in unload handler? The unload events are dispatched before Document::detach() is called in both LocalFrame::detach() and FrameLoader::commitProvisionalLoad(). So I think document().frame() must not be null in unload handler. LocalFrame::detach() m_loader.dispatchUnloadEvent(); document()->detach(); FrameLoader::commitProvisionalLoad() dispatchUnloadEvent(); m_frame->document()->detach(); https://codereview.chromium.org/1603783002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp (right): https://codereview.chromium.org/1603783002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:435: InspectorInstrumentation::didReceiveCORSRedirectResponse(document().frame(), resource->identifier(), document().frame()->loader().documentLoader(), redirectResponse, 0); On 2016/01/19 13:48:08, kinuko wrote: > We access document().frame() in a similar situation, do we have crashes for this > one? Should we protect this too? I can't find any crashes here.
tyoshino@chromium.org changed reviewers: + tyoshino@chromium.org
https://codereview.chromium.org/1603783002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp (right): https://codereview.chromium.org/1603783002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:435: InspectorInstrumentation::didReceiveCORSRedirectResponse(document().frame(), resource->identifier(), document().frame()->loader().documentLoader(), redirectResponse, 0); On 2016/01/20 03:57:36, horo wrote: > On 2016/01/19 13:48:08, kinuko wrote: > > We access document().frame() in a similar situation, do we have crashes for > this > > one? Should we protect this too? > > I can't find any crashes here. If the crash is happening (and the cause, frame() being null happening) only for sync loading cases as kinuko@ guessed, we shouldn't see crashes here as this path is reached only for async loading.
Hmm.. thanks for further investigation. Could we still have a brief description and link to the crbug in a comment? I'd like to avoid adding null checks without valid reasons. tyoshino-san: comments in xhr code seem to be a bit obsolete? It would be nice if clean it up a bit.
On 2016/01/20 08:20:41, kinuko wrote: > Hmm.. thanks for further investigation. Could we still have a brief description > and link to the crbug in a comment? I'd like to avoid adding null checks > without valid reasons. Done.
lgtm https://codereview.chromium.org/1603783002/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp (right): https://codereview.chromium.org/1603783002/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:574: // must be set here. FIXME: Find the root cause of the unset frame. TODO(horo) (or tyoshino or someone appropriate) We started to use TODO(name) instead of FIXME in blink too.
https://codereview.chromium.org/1603783002/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp (right): https://codereview.chromium.org/1603783002/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:574: // must be set here. FIXME: Find the root cause of the unset frame. On 2016/01/21 09:09:24, kinuko wrote: > TODO(horo) (or tyoshino or someone appropriate) > > We started to use TODO(name) instead of FIXME in blink too. Done.
The CQ bit was checked by horo@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from kinuko@chromium.org Link to the patchset: https://codereview.chromium.org/1603783002/#ps40001 (title: "use TODO")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1603783002/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1603783002/40001
Message was sent while issue was closed.
Description was changed from ========== Add null check of the return value of Document::frame() in DTL::reportResponseReceived() BUG=578849 ========== to ========== Add null check of the return value of Document::frame() in DTL::reportResponseReceived() BUG=578849 ==========
Message was sent while issue was closed.
Committed patchset #3 (id:40001)
Message was sent while issue was closed.
Description was changed from ========== Add null check of the return value of Document::frame() in DTL::reportResponseReceived() BUG=578849 ========== to ========== Add null check of the return value of Document::frame() in DTL::reportResponseReceived() BUG=578849 Committed: https://crrev.com/d2535dca624b5531247dbcbc2048dded6e9c45fc Cr-Commit-Position: refs/heads/master@{#370674} ==========
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/d2535dca624b5531247dbcbc2048dded6e9c45fc Cr-Commit-Position: refs/heads/master@{#370674}
Message was sent while issue was closed.
lgtm On 2016/01/20 08:20:41, kinuko wrote: > Hmm.. thanks for further investigation. Could we still have a brief description > and link to the crbug in a comment? I'd like to avoid adding null checks > without valid reasons. > > tyoshino-san: comments in xhr code seem to be a bit obsolete? It would be nice > if clean it up a bit. I'll try to. Filed http://crbug.com/580068 |
