[Webkit-unassigned] [Bug 137297] Allowing eval'ed code to be named in stack traces
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Oct 16 12:06:06 PDT 2020
https://bugs.webkit.org/show_bug.cgi?id=137297
--- Comment #10 from Joel Einbinder <einbinder at chromium.org> ---
(In reply to Devin Rousso from comment #9)
> Comment on attachment 411597 [details]
> Patch
>
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=411597&action=review
>
> > Source/JavaScriptCore/runtime/StackFrame.cpp:70
> > + String sourceURLDirective = m_codeBlock->ownerExecutable()->source().provider()->sourceURLDirective();
>
> Are we sure that `provider()` exists?
A few lines later, ownerExecutable()->sourceURL(), calls provider()->sourceURL() internally. I can add sourceURLDirective to ScriptExecutable to make it look less sketchy. I guess I was cutting corners in pursuit of a smaller patch.
> > LayoutTests/inspector/model/remote-object/error-expected.txt:34
> > + "_name": "sourceURL",
> > + "_type": "string",
> > + "_value": "__WebInspectorInternal__"
>
> This slightly concerns me, as it exposes the fact that the evaluation came
> from Web Inspector.
I totally agree that it's concerning. However I think it just makes it more clear what's going on. The stack trace from the console is already highly detectable. It looks like
global code
evaluateWithScopeExtension@[native code]
_wrapCall
Fixing this requires stripping the stack from the console evaluations. And even then, the lack of a stack could be detected. For comparison Firefox's stack is
@debugger eval code:1:1
Whereas Chromium's is
Error
at <anonymous>:1:1
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201016/0e0b8abd/attachment.htm>
More information about the webkit-unassigned
mailing list