Script list display a lot of @conn0.source# entries #7917

Closed
nicolasroux opened this Issue Jun 21, 2015 · 39 comments

Projects

None yet

6 participants

@nicolasroux

With FF 38.0.5 & FB 2.0.11
Goto http://aspectize.com
Open Firebug, and select script tab.
On the script list, there are many entries app.ashx@conn0.source# and firebug is very slow.
The script filter is set on static script only.
firebug

These shadows scripts seems to come from eval (this site if fully dynamic with all html produced in the browser and there are a lot of eval).
How can I disabled those scripts ? (as we are author of this technology, maybe we have to set something in our scripts to avoid this problem ?)

@fflorent
Member

You may want to use the sourceURL directive.

The computation of the URL should be a bit faster with it.

Florent

@nicolasroux

Thanks for your reply, sourceURL directive is helpful to allow developers to trace and add breakpoint in the script; is there any way to not display at all these scripts in firebug ?

@fflorent
Member

Unfortunately no. Even if the script type would hide these scripts but may not help in preventing Firebug from being slow (as I understand, that's one of the key points of your question). We may want to introduce a new option to entirely disable this feature entirely.

As a workaround, you can change in about:config the value of the extensions.firebug.maxNumberOfDynamicScripts option to 1 (0 would mean that you don't set any limit of the number of dynamic scripts you want to list).

Does it help?

Florent

@nicolasroux

No, it does not change anything.
My initial value of extensions.firebug.maxNumberOfDynamicScripts was 150 (default value ?); I have changed it to 1, but I still have a list of script with hundreds entries, which cause Firebug to be very slow.

@fflorent
Member

@janodvarko Is it OK to implement a new option in order to ignore dynamic script (that's a reasonable little feature that should help a lot)? I strongly believe it is the cause of slowness in many situation, and specifically here

Florent

@fflorent fflorent added the Debugger label Jun 25, 2015
@nicolasroux

@fflorent any news ? Seems to reproduce the issue also with Angular apps... (and so, I am a little surprised anyone noticed the issue).
It should impact memory usage as well ?

@fflorent
Member
fflorent commented Jul 2, 2015

No news, sorry. I don't have much time to contribute these times for personal reasons. I have pinged again @janodvarko by mail for this thread.

Florent

@janodvarko
Member

@fflorent: an option that is enabled by default sounds ok to me.

Honza

@fflorent
Member
fflorent commented Jul 7, 2015

@nicolasroux I'll take a look at it at the end of the week or during the week-end.

Florent

@nicolasroux

many thanks !

@fflorent
Member

@nicolasroux Could you give this build a try and share your feedback please?
https://drive.google.com/file/d/0B5NqEPwxS4QwYVQ0b0VaZXVpWDA/view?usp=sharing

Go to about:config => OK to be careful => search for "extensions.firebug.listenDynamicScripts" => set the value to false

Notes:

  • in order to install it, you should open the file with Firefox.
  • you may see dynamic scripts when you open Firebug the first time. After a reload, the scripts should not appear. I can improve that if that's still slow or annoying.

Thanks in advance

Florent

@nicolasroux

Yes, it works, I don't see the dynamic scripts anymore, that's really great !

I had to restart FF after setting the property.
At first sight, the search in the script seems to be much more faster.

Does the option "extensions.firebug.listenDynamicScripts" will be the official way to turn it off, or should there be an option in FireBug Menu ?

thanks a lot

@nicolasroux

Hummm I still got some entries as app.ashx@conn0.source#, much less than before, but there are some

@fflorent
Member

Great!

Does the option "extensions.firebug.listenDynamicScripts" will be the official way to turn it off, or should there be an option in FireBug Menu ?

We could add an entry... I don't know, @janodvarko ?

Hummm I still got some entries as app.ashx@conn0.source#, much less than before, but there are some

Yes, as I noted, they appear when Firebug opens. But after a page reload, they disappear, right?

As I mentioned, I can try to improve that. What I wanted to know first is whether there were speed improvements :)

Florent

@fflorent
Member

New update. Does it work better @nicolasroux?

Thanks in advance!
Florent

@nicolasroux

I have worked with the latest version for a few hours.

It's much better, I no longer have any entries @conn0.source...

The Script list is much faster, and also the code search.
Hard to say if there is an overall improvement in performance or memory.

@fflorent
Member

It's much better, I no longer have any entries @conn0.source...

Great, thanks for the update! So I am submitting a pull request.

Hard to say if there is an overall improvement in performance or memory.

Well, we're just maintaining this version. The next version of Firebug has been completely reworked to be built on top of the DevTools. See the firebug.next repository.

Florent

@fflorent
Member
fflorent commented Aug 4, 2015

Merged 72de594. Thanks for the report and your feedback @nicolasroux !

Florent

@fflorent fflorent closed this Aug 4, 2015
@giovannibgr

Hello @fflorent,

In which firebug version is this fix included?

I've got Firefox 40.0.3 with Firebug 2.0.12 and I'm still experiencing an identical issue with a lot of ...@server1.conn0.sourceXXXXX entries.

Is this a different issue (due to the "server1" prefix) or I'm using a version that does not contain the fix yet?

@nicolasroux

Hello @fflorent,

Entries are back !

My version of FF is 40.0.3 and FireBug is 2.0.12. I don't know if I need to change some settings or not...

Thanks for your help

@fflorent
Member

Hello @nicolasroux,

Argh, sorry, the commit message above is wrong! The option name has changed. To activate it, enable extensions.firebug.ignoreDynamicScripts in about:config.

Does it work?

In which firebug version is this fix included?

Hello @giovannibgr. In 2.0.12, that is now stable. Sorry for the delay.

Florent

@nicolasroux

yes, it works again, thanks.

@giovannibgr

Thanks++
The new setting name is indeed more intuitive, but didn't have the chance to guess it :)

@SINeWang
extensions.firebug.ignoreDynamicScripts

it works.

@nicolasroux

Hello @fflorent,

I think it is broken again...

I am in FF 41.0.1 and FB 2.0.12.
My option extensions.firebug.ignoreDynamicScripts is set to true.

And I can see a lot of entries in my script list, and FB is very slow...

@fflorent
Member
fflorent commented Oct 5, 2015

Weird, that works pretty fine on my machine. Is that on the same webpage?

What panels have you enabled?

What happens if you reset all Firebug options (if you don't care about your Firebug preferences) or if you install it on a fresh Firefox profile ?

Florent

@fflorent fflorent reopened this Oct 5, 2015
@nicolasroux

it's weired, I can't reproduce it, seems to work now...

I suggest you close the issue, and I ping you back if I see it again, with more information.

@fflorent
Member
fflorent commented Oct 8, 2015

OK, thanks for the feedback. Don't hesitate

@fflorent fflorent closed this Oct 8, 2015
@cFreed-AKA-Alf

Hi,

With FF 41.0.1 and FB 2.0.12, I'm experiencing a similar problem for a few days: while debugging, I get a lot of added mentions in scriptList, like edit@server1.conn0.source#### (where #### is a growing number). At the same time I get a few number of console errors "too much recursion", with a link to debugger eval code (line 1 col 15).

From these error messages and from reading the above posts, I first thought it came from some erroneous change in my code, notably involving eval()'s. So I looked at it searching something like that, but with no chance.

Now I just tried enabling the extensions.firebug.ignoreDynamicScripts option, and nothing changed.

Moreover there is something that sounds very weird to me.
Having loaded a page of my app I clicked a link leading to a function where I put a breakpoint.
From there, without ever run the next statement, I observe that the number of mentions in the scriptList keeps growing while I merely try to observe the pointed scripts contents.
Each time I simply choose one in the list and display it, the list grows by 30 or 50 lines!
The same happens when I toggle from Script panel to Console and vice-versa.

Last but not least, the involved scripts contents seem more and more pointless: at the beginning, approximatively 1 from 2 contained (function() { callback(); }); now (for example at edit@server1.conn0.source7587) most of them only contain callback.

Have you any idea about what may happen?
Thanks in advance.
Fred

@cFreed-AKA-Alf

Just after my previous post, I went back testing my app.
Then I found an error I was looking for, and that seemed totally foreign to the above mentioned problem, but it appears that it was the cause of the problem: now the scriptsList doesn't receive those supplemental lines.

Nevertheless I can't at all figure out how it may be related!

So FYI, here is the involved part of code:

  var $jqDialog = $('div.ui-dialog');
  if (doAttach) {
    // Attach $set either to <body> or to jQuery UI dialog.
    $set.appendTo($jqDialog/*.length*/ ? $jqDialog : 'body').show();
  } else {
    ...

The above commented part /*.length*/ was omitted, so because $jqDialog is always true, when it was empty the code resolved trying to append $set to the non-existing $jqDialog-supposed-contained element.
But IMO this should not result in anything else than $set not attached anywhere, especially as we are used to see jQuery have a robust "mere-no-response" rule each time it cannot work.

Nevertheless, assuming it might be a jQuery bug, can you figure out how it can result in the infinite growing scriptsList previously described?

Thanks in advance for any advice.
Fred

@giovannibgr

Hello @fflorent,

I have the notion that the new occurrence of the multiplicated server1.conn0.source entries may be triggered by selecting a more or less complex expression in the debugger and trying to see what it evaluates to in the tooltip (a relatively new feature in FB).
At least in my case, when I try to select expressions in the Debugger window, the selection refuses to follow the mouse, FB freezes and then I can see the new entries in the scripts list.

And yes, the new thing here is the too much recursion errors in FB. They come out in my case too, not sure if they are related to the issue.

@cFreed-AKA-Alf

@giovannibgr What you wrote inspires me some additional comments, though I'm a bit embarrassed to think they really related to the multiple scriptsList entries issue.

You're talking about FB freezing when it happens: I agree but for me it's only freezing more!
In other words I'm experiencing FB freezing (notably remarkable when selecting an expression, as you cited) for a long time. Seems to happen since highlighting was added to the Debugger display.
Compared to older FB versions, some freezing can also be remarked when debugging large scripts (over 500 lines): using mouse wheel to browse the code is almost non-responding, and if I move the mouse pointer to the scroll-bar it is slow to toggle from text-cursor to usable pointer.

All that makes me think there is some supplemental huge work implied continuously as of this highlighting-able version. And so it would be even more remarkable when facing an issue like the one we're talking about.

In the other hand you also experience the too much recursion errors, but are not sure they are related to the issue. But for me they come **only* with the multiple scriptsList lines.
What puzzles me is that the number of these errors is much less than the number of additional script lines: e.g. in during my last test (stay on a break-point, then toggle between Console and Debugger tabs) I got 26 too much resursion errors while source entries number growed by ~2500.

Another last point: during previous tests, when I arrived to my first break-point, the Stack tab displayed only an advice like "stack displayed only when debugging"! Only after several steps down I got the expected stack information.
Again here, seems that the normal work of the debugger was so much slowed that it didn't even reached the point where it can display normal information?

I'm conscious that all the above is a bit messy but hope it helps to understand more about the issue.

Fred

@fflorent
Member

Thanks for the report. I am working on it.

Florent

@fflorent fflorent reopened this Oct 13, 2015
@fflorent
Member

I reported a new issue above with a fix and a try-build. Does it solve your issue ?

Florent

@cFreed-AKA-Alf

@fflorent Thanks to have been working on this.

First I followed your instructions in #7954 and yes: I experienced the problem.

Then having installed the try-build you proposed, I intentionally reproduced in my app the error which had previously led to this problem too.
And now, despite of the error, it works fine for the rest!

Only one point puzzles me: displaying tooltips when hovering was a great help; is it to be definitely absent, or is only a temporary workaround?
Anyway, thanks again.

Fred

@giovannibgr

@cFreed-AKA-Alf The multiple dynamic entries are gone for me too, but I can also see tooltips, they are not gone for me.
Simple variables' values are shown immediately and I can also select some simple expressions and they are evaluated after a while. Note that the delay in my case should be due to the large JS codebase - I'm debuggind 25000-line file which is one among 10 such files (excluding ExtJS framework, which is a hog on itself)

@cFreed-AKA-Alf

@giovannibgr Thanks for having pointed this.
@fflorent Don't care of my previous post: tooltips are not gone.

Sure I was a bit tired when I lastly controlled that: now I'm pretty sure I tried to hover expressions while not debugging! :-)

@fflorent
Member

Thank you both for the feedback ! :)

I close the issue. If you want to discuss a bit more, you may answer in the other issue.

@giovannibgr I am not sure why it takes so long, I can take a closer look at some point. Probably because of parsing issues.

Florent

@fflorent fflorent closed this Oct 14, 2015
@cFreed-AKA-Alf

@fflorent I close the issue: that's ok for me.
Many thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment