FireBug 1.9.0-a5 Bug Report.

[Anibal Svarcas]

I don't know if this is the right please to send a bug report, but
here it is:


· Setting up the bug reproduction enviroment:

- Using FireBug 1.9.0-a5 on FireFox 8.0 (Windows XP + SP3).
- "Console" tab Enabled. IMPORTANT: Only "Strict Warnings (performance
penalty)" config is set for this tab.
- "Script" tab Disabled.
- "Net" tab Disabled.
- All other FireBug options set by default.
- All other FireFox 8.0 plugins / extensions disabled.

· Reproducing the bug:

1.- Go to this site: http://docs.sencha.com/ext-js/4-0/

RESULT: The page never loads.

NOTE: It loads with FireBug disabled or at lest with "Strict Warnings
(performance penalty)" config unset.

[Jan Honza Odvarko]

On Friday, November 11, 2011 1:35:29 AM UTC+1, Anibal Svarcas wrote:

I don't know if this is the right please to send a bug report, but
here it is:

It's the right place.
 

· Setting up the bug reproduction enviroment:

- Using FireBug 1.9.0-a5 on FireFox 8.0 (Windows XP + SP3).
- "Console" tab Enabled. IMPORTANT: Only "Strict Warnings (performance
penalty)" config is set for this tab.
- "Script" tab Disabled.
- "Net" tab Disabled.
- All other FireBug options set by default.
- All other FireFox 8.0 plugins / extensions disabled.

· Reproducing the bug:

1.- Go to this site: http://docs.sencha.com/ext-js/4-0/

RESULT: The page never loads.

NOTE: It loads with FireBug disabled or at lest with "Strict Warnings
(performance penalty)" config unset.

I can't reproduce the problem, the page loads for me even if "string warnings" option is set.
But yes, it's slower since a lot of errors is reported (you can check Firefox Error Console)

Anybody else can repro the problem?

Honza
 

[Sebo]

I see the browser hanging ant I get "unresponsive script" messages when testing this with FB 1.8.4 and 1.9.0a5 on Win7 with FF 8.0.
For 1.9.0a5 I first get this for firebug-trace-service.js, line 356. Clicking "Stop script" then I get it at firebug-service.js, line 4212 continuously.

Sebastian

[Jan Honza Odvarko]

What should I do to repro the problem?

Honza

[Sebo]

Did you reload the page with Ctrl+F5?
Besides that I just followed the instructions above - means resetting the options and turning on strict warnings. Tested this on my normal profile as well as on a new profile.
Also the memory consumption goes up very fast from ~100 MB to infinite while the page loads and I choose to continue script execution. As soon as I choose to stop the script execution it goes down again to ~200 MB.

Sebastian

[Sebo]

If it helps anything, I attached two screenshots of about:memory. The first one shows the memory use before reloading and the second one after reloading (GC seems to have tightened up already).

Sebastian

[Steven Roussey]

Odd, I can't reproduce it either. I have that page open quite often, with Firebug and Illuminations installed.

[Jan Honza Odvarko]

OK, I was able to reproduce the problem, but I don't know how to fix it.

There is too many reported warning, which (a) slows down the entire browser and (b) takes a lot of memory.

We should probably try to fix issue 511, that would reduce number of warnings, but even then the amount of warnings coming from the page could have the same effect.

Honza

[Steven Roussey]

OK, I was able to reproduce the problem, but I don't know how to fix it.

What did you do to see it?

 

There is too many reported warning, which (a) slows down the entire browser and (b) takes a lot of memory.

Are we storing these in Firebug? I don't see them.

 

We should probably try to fix issue 511, that would reduce number of warnings, but even then the amount of warnings coming from the page could have the same effect.

 OK, I re-read. So this has to do with javascript.options.strict set to true? I almost think that Firebug should be disabled in such a case. The "IMPORTANT" message in the console is not a big enough warning I guess. It should say something like "WARNING: javascript.options.strict set to true and could cause your browser to lock up. Click here to return to default". I guess I should check well how the built-in HUD works.

[Sebo]

There is too many reported warning, which (a) slows down the entire browser and (b) takes a lot of memory.

Are we storing these in Firebug? I don't see them.

 

We should probably try to fix issue 511, that would reduce number of warnings, but even then the amount of warnings coming from the page could have the same effect.

 OK, I re-read. So this has to do with javascript.options.strict set to true? I almost think that Firebug should be disabled in such a case. The "IMPORTANT" message in the console is not a big enough warning I guess. It should say something like "WARNING: javascript.options.strict set to true and could cause your browser to lock up. Click here to return to default". I guess I should check well how the built-in HUD works.

Disabling Firebug is not the solution in my eyes, because users want to see that messages in Firebug. That's why we have that option.
The solution needs to be to improve the display performance of the Console panel. To achieve that there's the possibility to implement a caching mechanism as we have it in the Script panel. Though that would need a lot of effort to integrate.
I just still wonder why we have that problem, because there's already a display limit (set to 500 by default) for console messages.
Also I believe, changing the Console panel to use e10s will have a high impact on performance.

Sebastian

[Jan Honza Odvarko]

On Tuesday, November 22, 2011 2:56:25 AM UTC+1, Steven Roussey wrote:

OK, I was able to reproduce the problem, but I don't know how to fix it.

What did you do to see it?

 
1) Set "Strict Warnings" in the Console mini-tab menu on.

2) Load/reload http://docs.sencha.com/ext-js/4-0/

The difference from the Web Console (buil-in) is that Firebug is using JSD to get stack-frames for the error/warning location, which is slow. Now I also think that the memory consumption is caused by a lot of information gathered by Firebug during that process.

Here is the time-consuming function:
http://code.google.com/p/fbug/source/browse/branches/firebug1.9/content/firebug/js/debugger.js#1363

We could perhaps do following:

if (Options.getPref("javascript.options", "strict");)
    Firebug.errorStackTrace = StackFrame.getCorrectedStackTrace(frame, context);

So, stack would be generated from Components.stack, it would be faster but sometimes wrong.

> Disabling Firebug is not the solution in my eyes, because users want to see that messages in Firebug.
> That's why we have that option.

I also think Firebug should be enabled.

> Also I believe, changing the Console panel to use e10s will have a high impact on performance.

I don't think e10s would have any impact on this.

Honza