|
|
Created:
4 years, 5 months ago by Charlie Reis Modified:
4 years, 5 months ago CC:
blink-reviews, blink-reviews-api_chromium.org, chromium-reviews, creis+watch_chromium.org, darin-cc_chromium.org, dglazkov+blink, gavinp+loader_chromium.org, jam, Nate Chapin, kinuko+watch, loading-reviews_chromium.org, mlamouri+watch-content_chromium.org, nasko+codewatch_chromium.org, tyoshino+watch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionNotify the Blink client synchronously if the initial doc is accessed.
This avoids problems with the timer being delayed by nested message
loops and ScopedPageLoadDeferrers, where code in the nested message
loop might access the document and not generate a notification.
The timer was originally added to prevent re-entrant calls to V8,
but that can now be prevented with ScriptForbiddenScope.
BUG=629542
TEST=See bug for repro steps.
Committed: https://crrev.com/00314989401bfee5ffcb5e579162071c86e72f61
Cr-Commit-Position: refs/heads/master@{#407269}
Patch Set 1 #Patch Set 2 : Forbid scripts. #
Total comments: 6
Patch Set 3 : Fix comments. #
Messages
Total messages: 32 (20 generated)
The CQ bit was checked by creis@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
creis@chromium.org changed reviewers: + dcheng@chromium.org
Daniel, what do you think? Is this safer than what we have today? (This is mainly for discussion, but we can proceed with it if it seems reasonable.)
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
Maybe we could throw a ScriptForbiddenScope on the stack if we're worried about re-entering v8. I don't /think/ that will break anything that's currently running, but I'm not 100% sure...
The CQ bit was checked by creis@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
On 2016/07/22 03:36:28, dcheng wrote: > Maybe we could throw a ScriptForbiddenScope on the stack if we're worried about > re-entering v8. I don't /think/ that will break anything that's currently > running, but I'm not 100% sure... Giving it a try in patch set 2.
PS2 LGTM assuming the bots are happy. https://codereview.chromium.org/2171063002/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/FrameLoader.cpp (right): https://codereview.chromium.org/2171063002/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/FrameLoader.cpp:1063: // Notify synchronously. The client must be careful not to re-enter the Nit: "Forbid script execution to prevent re-entering V8, since this is called from a binding security check." https://codereview.chromium.org/2171063002/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/FrameLoaderClient.h (right): https://codereview.chromium.org/2171063002/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/FrameLoaderClient.h:128: // this notification. It makes me sad that this comment is necessary, since it really should be the default for most callbacks. I'm honestly OK not having it at all actually, since ScriptForbiddenScope will explode even in release mode. Similar thought for the comment in WebFrameClient.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
dglazkov@chromium.org changed reviewers: + dglazkov@chromium.org
https://codereview.chromium.org/2171063002/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/FrameLoaderClient.h (right): https://codereview.chromium.org/2171063002/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/FrameLoaderClient.h:129: virtual void didAccessInitialDocument() { } The only user of this is RenderFrameImpl::didAccessInitialDocument, right? I hope we're not planning to add overrides to this function.
Description was changed from ========== Notify the Blink client synchronously if the initial doc is accessed. This avoids problems with the timer being delayed by nested message loops and ScopedPageLoadDeferrers, where code in the nested message loop might access the document and not generate a notification. The risk is that clients might try to call back into V8 from the notification, which would be re-entrant. Updated documentation to make it clearer that this would be a problem. BUG=629542 TEST=See bug for repro steps. ========== to ========== Notify the Blink client synchronously if the initial doc is accessed. This avoids problems with the timer being delayed by nested message loops and ScopedPageLoadDeferrers, where code in the nested message loop might access the document and not generate a notification. The timer was originally added to prevent re-entrant calls to V8, but that can now be prevented with ScriptForbiddenScope. BUG=629542 TEST=See bug for repro steps. ==========
The CQ bit was checked by creis@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Thanks. I like the new approach with ScriptForbiddenScope-- it accomplishes the original goal (no V8 re-entrancy) without all the loopholes for URL spoofing. dglazkov@, are you ok with proceeding? https://codereview.chromium.org/2171063002/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/FrameLoader.cpp (right): https://codereview.chromium.org/2171063002/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/FrameLoader.cpp:1063: // Notify synchronously. The client must be careful not to re-enter the On 2016/07/22 06:22:03, dcheng wrote: > Nit: "Forbid script execution to prevent re-entering V8, since this is called > from a binding security check." Done. https://codereview.chromium.org/2171063002/diff/20001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/FrameLoaderClient.h (right): https://codereview.chromium.org/2171063002/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/FrameLoaderClient.h:128: // this notification. On 2016/07/22 06:22:03, dcheng wrote: > It makes me sad that this comment is necessary, since it really should be the > default for most callbacks. I'm honestly OK not having it at all actually, since > ScriptForbiddenScope will explode even in release mode. Similar thought for the > comment in WebFrameClient. Yeah, I added it before we had the ScriptForbiddenScope, and I didn't have time to revisit it last night when kicking off the try jobs for the new approach. I've removed them. https://codereview.chromium.org/2171063002/diff/20001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/FrameLoaderClient.h:129: virtual void didAccessInitialDocument() { } On 2016/07/22 14:32:10, dglazkov wrote: > The only user of this is RenderFrameImpl::didAccessInitialDocument, right? I > hope we're not planning to add overrides to this function. That's right. That's the only use, and there's no plans to add any more.
lgtm
The CQ bit was unchecked by creis@chromium.org
The CQ bit was checked by creis@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org Link to the patchset: https://codereview.chromium.org/2171063002/#ps40001 (title: "Fix comments.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by creis@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Notify the Blink client synchronously if the initial doc is accessed. This avoids problems with the timer being delayed by nested message loops and ScopedPageLoadDeferrers, where code in the nested message loop might access the document and not generate a notification. The timer was originally added to prevent re-entrant calls to V8, but that can now be prevented with ScriptForbiddenScope. BUG=629542 TEST=See bug for repro steps. ========== to ========== Notify the Blink client synchronously if the initial doc is accessed. This avoids problems with the timer being delayed by nested message loops and ScopedPageLoadDeferrers, where code in the nested message loop might access the document and not generate a notification. The timer was originally added to prevent re-entrant calls to V8, but that can now be prevented with ScriptForbiddenScope. BUG=629542 TEST=See bug for repro steps. ==========
Message was sent while issue was closed.
Committed patchset #3 (id:40001)
Message was sent while issue was closed.
Description was changed from ========== Notify the Blink client synchronously if the initial doc is accessed. This avoids problems with the timer being delayed by nested message loops and ScopedPageLoadDeferrers, where code in the nested message loop might access the document and not generate a notification. The timer was originally added to prevent re-entrant calls to V8, but that can now be prevented with ScriptForbiddenScope. BUG=629542 TEST=See bug for repro steps. ========== to ========== Notify the Blink client synchronously if the initial doc is accessed. This avoids problems with the timer being delayed by nested message loops and ScopedPageLoadDeferrers, where code in the nested message loop might access the document and not generate a notification. The timer was originally added to prevent re-entrant calls to V8, but that can now be prevented with ScriptForbiddenScope. BUG=629542 TEST=See bug for repro steps. Committed: https://crrev.com/00314989401bfee5ffcb5e579162071c86e72f61 Cr-Commit-Position: refs/heads/master@{#407269} ==========
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/00314989401bfee5ffcb5e579162071c86e72f61 Cr-Commit-Position: refs/heads/master@{#407269} |