Bug 146049 – Web Inspector: Do not show JavaScriptCore builtins in inspector

• Component: Web Inspector
• Status: RESOLVED FIXED

[Joseph Pecoraro]

* SUMMARY
Do not show JavaScriptCore builtins in inspector.

* STEPS TO REPRODUCE
1. Inspect about:blank
2. Do a global search for "@call"
  => get to see the source for things like Function.prototype.call and Array.prototype.map

* NOTES
- The format is a pseudo JavaScript that doesn't parse as proper JavaScript so syntax-highlighting is off
- Breakpoints don't really work in built-ins, though we somehow can pause in the scripts, so the experience is poor if we did allow it for now

[Joseph Pecoraro]

Created attachment 255002 [details]
[PATCH] Proposed Fix

[Joseph Pecoraro]

*** Bug 145654 has been marked as a duplicate of this bug. ***

[Joseph Pecoraro]

<rdar://problem/21247912>

[WebKit Commit Bot]

Comment on attachment 255002 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 255002

Committed r185670: <http://trac.webkit.org/changeset/185670>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Csaba Osztrogonác]

(In reply to comment #4)
> Comment on attachment 255002 [details]
> [PATCH] Proposed Fix
> 
> Clearing flags on attachment: 255002
> 
> Committed r185670: <http://trac.webkit.org/changeset/185670>

It made 2 tests fail everywhere. Could you check it?
Maybe updating the expected file is the proper fix.

[Joseph Pecoraro]

(In reply to comment #6)
> (In reply to comment #4)
> > Comment on attachment 255002 [details]
> > [PATCH] Proposed Fix
> > 
> > Clearing flags on attachment: 255002
> > 
> > Committed r185670: <http://trac.webkit.org/changeset/185670>
> 
> It made 2 tests fail everywhere. Could you check it?
> Maybe updating the expected file is the proper fix.

Interesting. I have yet to reproduce this myself running the fast/profiler directory to these tests individually. I'm updating to see if I can reproduce.

I agree, updating the expected results would be good, but it also seems as if the bots get different results from time to time.

[Joseph Pecoraro]

I am still unable to reproduce locally, but the bots can reproduce a lot. Rather than keep them red, I rolled this out while I investigate.

https://trac.webkit.org/changeset/185715

[Joseph Pecoraro]

*** Bug 150710 has been marked as a duplicate of this bug. ***

[Joseph Pecoraro]

Last time we tried this it broke profiler tests, and I think that was because we were doing this in the Recompiler visiting. This time I'm doing the same thing but gathering the list of sources to inform the inspector about is separate from recompiling. Take 2!

[Joseph Pecoraro]

Created attachment 264381 [details]
[PATCH] Proposed Fix

[Geoffrey Garen]

Comment on attachment 264381 [details]
[PATCH] Proposed Fix

r=me

Can we test this?

[Joseph Pecoraro]

(In reply to comment #12)
> Comment on attachment 264381 [details]
> [PATCH] Proposed Fix
> 
> r=me
> 
> Can we test this?

We can write some form of test. I'll look into that tomorrow.

In this case we could do a search for "@call" and ensure that we don't see such results, but that test is weak in the sense that if built-ins ever change syntax and that "@call" or some equivalent goes away and we end up testing nothing. Still worth looking into though!

[WebKit Commit Bot]

Comment on attachment 264381 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 264381

Committed r191779: <http://trac.webkit.org/changeset/191779>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.