Bug 9895 – Unloaded files still show in Drosera's file dropdown

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Web Inspector (Deprecated)

[Jonathan Hurshman]

Drosera's dropdown lists all the scripts the browser has seen since it was attached. Unloaded files are (as far as I can tell) never removed. This rapidly gets confusing.

The dropdown should show only files/scripts which are presently loaded and available.

[Vladimir Olexa (vladinecko)]

This bug is related to Bug 12887.

[Timothy Hatcher]

This is less of an issue with the Web Inspector debugger because we only show scripts since the last load. But the list will still fill up with scripts that aren't used anymore.

[Joseph Pecoraro]

I don't know about "unloaded files" anymore but certainly every single time you execute a command in the Console a new "(program)" shows up in the Script's drop down list.  For example:
http://grab.by/6X3

Note that you also see the Injected command line API:
http://grab.by/6X4

Are these changes related to how InjectedScript works (pfeldman)?

[Pavel Feldman]

(In reply to comment #3)
> I don't know about "unloaded files" anymore but certainly every single time you
> execute a command in the Console a new "(program)" shows up in the Script's
> drop down list.  For example:
> http://grab.by/6X3
> 
> Note that you also see the Injected command line API:
> http://grab.by/6X4
> 
> Are these changes related to how InjectedScript works (pfeldman)?

Every time something is evaluated using console / watch expressions / any eval in the inspected page, compile -> run takes place under the hood. It reports compiled scripts to the inspector and hence they appear in the UI. Due to the original bug described here, collected scripts are not removed from the frontend.

We could wrap service evals and filter them from the UI, but that might lead to the following problem. Imagine you override some function definition using console (functionFoo = function() { do-something-new }). Then you debug the control flow that is getting into this function. You'd like to have a snippet available in the scripts list in order to step through it. So real solution to this problem is to report collected scripts into the framework.

As a short term fix we could try marking these scripts as 'hidden', not adding them into the scripts list, but displaying the snippet content when it is present in a backtrace while debugging. Timothy, what do you think?

[Timothy Hatcher]

(In reply to comment #4)
> (In reply to comment #3)
> As a short term fix we could try marking these scripts as 'hidden', not adding
> them into the scripts list, but displaying the snippet content when it is
> present in a backtrace while debugging. Timothy, what do you think?

I like that idea, it might be better than just short term.

[Joseph Pecoraro]

> As a short term fix we could try marking these scripts as 'hidden', not adding
> them into the scripts list, but displaying the snippet content when it is
> present in a backtrace while debugging.

If I remember correctly, the Console's typeahead is using evals.  So whenever you see a type ahead pop up in the Console, you get something ugly in the scripts list:
http://grab.by/6YB

If anything I think those typeahead helpers should be hidden, or even eliminated because they will never be needed again.

But I see your point with overriding functions and wanting to step through them, or even set breakpoints.

[Alexander Pavlov (apavlov)]

I'm no longer seeing odd scripts, and apparently the typeahead scripts are no more added to the script list, too.