Callframe is empty when content script is paused by debugger instruction.
Reported by
findwa...@126.com,
Jun 6 2016
|
|||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Steps to reproduce the problem: 1. Run chrome with --silent-debugger-extension-api command line option 2. Load the unpacked extension from the attachment 3. Navigate to "www.google.com" 4. The callframe of content script is empty What is the expected behavior? Developer should be able to get the callframe information of content script. What went wrong? The callframe are empty. Did this work before? Yes Tested version 50 and 46, both work as expected. Chrome version: 51.0.2704.79 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 21.0 r0
,
Jun 6 2016
Adding more detail about the extension in the attachement. Background page will attach to each web page via chrome.debugger API and listen on "Debugger.paused" event. If a breakpoint is triggered, the callframes will be printed in the console of the background page. In content script(ContentScriptWorker.js), "debugger" instruction will be called after some delay(to make sure background is attached to current page). I'm expecting to get the callframes of the content script code. The callframes are always empty in chrome version 51 while the callframes are correct in version 50 and 46. There seems to be something wrong in version 51. Please compare the console log from the attachment for version 51 and version before 51.
,
Jun 9 2016
Thanks for the repro steps! Narrow bisect done. Suspecting commit: https://chromium.googlesource.com/chromium/src/+/3ba0c2fb4f8ecd2315828043d4e5508915c2f99c
,
Jun 14 2016
Thanks for the quick investigation. My company developed a extension and plan to release it around August. This extension depends on chrome debugger mechanism heavily. It breaks on version 51 due to the bug I submitted. May I know the time frame you plan to fix this bug? It would be great if this bug can be fix in a stable version released before August. Thanks & Regards
,
Jun 16 2016
,
Jun 16 2016
,
Jun 16 2016
Patch is on the way: https://codereview.chromium.org/2064133002/
,
Jun 16 2016
A friendly reminder that M52 Stable is launching soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch by July 12. All changes MUST be merged into the release branch by 5pm on July 15 to make into the desktop Stable final build cut. Thank you!
,
Jun 20 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/151d5d907870e262ff7f94fd4b1f1e5ef887e96d commit 151d5d907870e262ff7f94fd4b1f1e5ef887e96d Author: dgozman <dgozman@chromium.org> Date: Mon Jun 20 20:34:57 2016 [DevTools] Explicitly reset context group when clearing ScriptController. Previously, we assumed that main world context creation means reset. This is not the case when content script is executed before main world script, and we ended up with content script context being cleared from debugger. Now we get explicit notification from ScriptController to reset (mainly on navigation). BUG= 617530 Review-Url: https://codereview.chromium.org/2064133002 Cr-Commit-Position: refs/heads/master@{#400770} [modify] https://crrev.com/151d5d907870e262ff7f94fd4b1f1e5ef887e96d/content/renderer/render_view_browsertest.cc [modify] https://crrev.com/151d5d907870e262ff7f94fd4b1f1e5ef887e96d/third_party/WebKit/Source/bindings/core/v8/ScriptController.cpp [modify] https://crrev.com/151d5d907870e262ff7f94fd4b1f1e5ef887e96d/third_party/WebKit/Source/core/inspector/MainThreadDebugger.cpp [modify] https://crrev.com/151d5d907870e262ff7f94fd4b1f1e5ef887e96d/third_party/WebKit/Source/core/inspector/MainThreadDebugger.h
,
Jun 23 2016
@dgozman: Could you please have a look at the attached video and let us know if this is the expected behavior. If yes, we can add the TE-Verified labels. Thank you.
,
Jun 23 2016
Re #c10: you have to open DevTools window not for the page, but for the extension: go to chrome://extensions and click on "Inspect views: background page" link for the installed extension. There, you should see "size of callframes is 4".
,
Jun 27 2016
** IMPORTANT change in M52 merge date due to first 2 weeks of July no release weeks ** M52 Stable is launching very soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged ASAP. All changes MUST be merged into the release branch by 5pm on July 1 to make into the desktop Stable final build cut. Thank you!
,
Jun 27 2016
Could you please verify this issue? See #c10 and #c11 for more details.
,
Jun 28 2016
@dgozman: Unable to repro this issue on Windows 7 for Google Chrome Stable Version - 51.0.2704.106 "Size of Call callframes is 4" is displayed for www.google.com with the flag "#silent-debugger-extension-api" enabled. Screen-recording is attached. COuld you please let us know if this is the correct procedure. Thank you.
,
Jun 28 2016
,
Jun 28 2016
,
Jun 28 2016
,
Jun 28 2016
Thank you for verification, that's perfect! Requesting merge to M52.
,
Jun 28 2016
Your change meets the bar and is auto-approved for M52 (branch: 2743)
,
Jun 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/87c1e7416fb66c6892abb38d9295c611e03e1157 commit 87c1e7416fb66c6892abb38d9295c611e03e1157 Author: Dmitry Gozman <dgozman@chromium.org> Date: Tue Jun 28 17:19:56 2016 Merge to 2743 "[DevTools] Explicitly reset context group when clearing ScriptController." > [DevTools] Explicitly reset context group when clearing ScriptController. > > Previously, we assumed that main world context creation means reset. > This is not the case when content script is executed before main world script, > and we ended up with content script context being cleared from debugger. > Now we get explicit notification from ScriptController to reset (mainly on navigation). > > BUG= 617530 > > Review-Url: https://codereview.chromium.org/2064133002 > Cr-Commit-Position: refs/heads/master@{#400770} (cherry picked from commit 151d5d907870e262ff7f94fd4b1f1e5ef887e96d) TBR=pfeldman@chromium.org Review URL: https://codereview.chromium.org/2105853002 . Cr-Commit-Position: refs/branch-heads/2743@{#505} Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939} [modify] https://crrev.com/87c1e7416fb66c6892abb38d9295c611e03e1157/content/renderer/render_view_browsertest.cc [modify] https://crrev.com/87c1e7416fb66c6892abb38d9295c611e03e1157/third_party/WebKit/Source/bindings/core/v8/ScriptController.cpp [modify] https://crrev.com/87c1e7416fb66c6892abb38d9295c611e03e1157/third_party/WebKit/Source/core/inspector/MainThreadDebugger.cpp [modify] https://crrev.com/87c1e7416fb66c6892abb38d9295c611e03e1157/third_party/WebKit/Source/core/inspector/MainThreadDebugger.h
,
Jun 28 2016
,
Jun 30 2016
Verified the fix on Windows 7 for Google Chrome Beta Version - 52.0.2743.60 Followed the steps in the comment #15 Screen-shot is attached. TE-Verified labels are attached. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by findwa...@126.com
, Jun 6 20161.9 KB
1.9 KB Download