Closed Bug 815603 Opened 12 years ago Closed 10 years ago

JSD.pause and unPause is slow

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID
Milestone:
mozilla27
Tracking Flags:
Tracking Status
firefox27 + verified

People

(Reporter: Honza, Unassigned)

References

Details

(Keywords: feature, Whiteboard: [Snappy])

Attachments

(4 files)

Test extension
2.51 KB, application/x-xpinstall
Details
firebug-1.13.0a3.6086.xpi
2.12 MB, application/x-xpinstall
Details
Firebug-1.13.0a3.6086.png
247.33 KB, image/png
Details
firebug-1.12.4.6942.xpi
2.11 MB, application/x-xpinstall
Details
Attached file Test extension — 
This bug has been originally reported in Firebug issue list here:
http://code.google.com/p/fbug/issues/detail?id=6086

The problem is that pausing and unpausing JSD is really slow.

STR:

1) Install the attached extension
The source is here:
https://github.com/firebug/manual-tests/commits/master

2) Open several Firefox tabs: gmail.com 5x, Etherpad 1x, github.com 2x, 

3) Right click on page and see the context menu. Pick pause/unpause and check out the alert with number of milliseconds it freezes the browser.

The original purpose of pause/unpause was to be quick and replace activate/deactivate, which is slow. So, this sounds like a bug.

Honza
Forgot to note, I am seeing ~500 ms delay when doing pause/unpause.
Another report (from Firebug team member) says 600-1000 ms

Honza
FWIW here are some results of my testings:

FF 4.0: ~1ms
FF 10.0: ~40ms
FF 15.0: ~140ms
FF 17.0: ~400ms
FF 20.0a1: ~320ms

Obviously pause/unpause got dramatically slower with each tested version.

Sebastian
I believe the problem is that unpausing involves throwing away jitcode and the like, no?  And doing that for all compartments, because the jsd api doesn't let you debug per-compartment sanely...
Firebug is really struggling with this problem and we are (Firebug team) regularly getting reports from Firebug users about slow tab switching if JSD1 is on.

Here is the Firebug side report:
http://code.google.com/p/fbug/issues/detail?id=6086

Even if we are hardworking on JSD2 adoption it can yet take some time till Firebug with full JSD2 support is released (e.g. we are blocked by bug Bug 911721).

Could we raise priority of this report and get it fixed?
That would be great help for Firebug!

Honza
I am seeing very long pauses when tab switching with firebug enabled, however, my OS is Linux FC 19 and not Windows Vista. Is that platform setting actually correct? While the symptoms sound the same (FF 24.0), how can I be sure this is the same bug?
Also seeing very long pauses under Linux Ubuntu 13.04 x64 with Firebug enabled (and switched to Chrome while this bug exists).

Danny, I think Honza is aware that this bug is not specific to Vista (see firebug http://code.google.com/p/fbug/issues/detail?id=6086 ), but this Firefox-side bug probably should be re-categorized as Platform:All instead of Platform:x86 Windows Vista.
OMG, I have now figured out why my firefox was so unbearably slow (Mac OS X & Windows) after all these years. It was Firebug!!! Don't know why I couldn't connect the dots but then again I have so many firefox extensions installed.
yes, with cmd alt k doing almost the same stuff, it is very tempting to uninstall it.
According with Ronan Jouchet, this problem happens with ALL platforms(tested in windows and ubuntu).
Is this issue also causing any problems with the Javascript 'setTimeout' method?
Example: setTimeout("Javascript code;", 1000) - I noticed some issues on some local code that didn't work with Firebug tool enabled. 

When I disabled Firebug, this problem seemed to go away.
amrita> probable not the same issue.

Jan> here's some crazy idea: could we stop using JSD.pause/unPause in Firebug? I mean, it was used at a time it was fast, as a mean to leave non-debugged page fast. But nowadays, I think using pause/unPause just gives more problem than improvements, and so we could temporarily remove their usage until either this bug is fixed or your work on porting Firebug to JSD2 is finished.
Confirmed for OS X. Values for UnPause are between 240 and 360ms.
Yeah, [Ubuntu 13.04 / FF 24.0 / FB 1.12.3]. Between accidently hitting f12 and it automagically opening on previously used pages, my system was grinding to a halt. Firefox would grey out each time for over a minute.

Disabled the script panel anyway.
This bug has been driving me nuts for a long time. I've resorted to opening Chrome instead of opening another tab lately as a workaround. Problem persists on Ubunut 13.10, Firefox 25b1, Firebug 1.12.3.
Since I don't think it's been mentioned here, all you have to do to make everything fast again is disable the 'script' panel in Firebug until all this is fixed. If you have to use it, then just make sure to disable it again before switching tabs so it's not so slow.
Test Firebug build with a possible workaround.

Could anybody please check it out and let me know if it helps?

Thanks!

Honza
Comment on attachment 815893 [details]
firebug-1.13.0a3.6086.xpi

Seems to fix the problem for me.
(In reply to Jan Honza Odvarko from comment #17)

Amazing! The problem seems to be completely solved with this workaround. Thank you.
Thanks for the feedback.

Please give it some time and let me know if there are any bad side effects.

Thanks!
Honza
Thank you for this latest version of Firebug. I have been using it for a bit now without noticing anything odd. And yes, it does indeed seem to sort this issue out.
I used it throughout my work day today and it definitely fixes the tab switching slowness. The only thing I noticed is that it seemed like with the script tab enabled there was a little slowness/lag with the JavaScript that runs to load my web app every time I would refresh the page. It's way better than it was though. Good work!
(In reply to Jan Honza Odvarko from comment #20)
> Thanks for the feedback.
> 
> Please give it some time and let me know if there are any bad side effects.
> 
> Thanks!
> Honza

Your fix works fine for me too, thank you very much!
Firefox 25.0b7, Mac OS X 10.8.5 (12F45)
I'm using Firefox 24 on Ubuntu Linux (Raring Ringtail).
I'm one of those users with hundres of tabs and I passed from seconds to switch tabs to unnoticeable time. 
Well done.
Hello,
I'm using Firefox 24 on Kubuntu 12.04. It took about 15 seconds to switch between tabs, now it takes about 0,1 second. I'll keep using it to see if there are any other issues with this workaround.
And thanks a lot for this awesome extension!
(In reply to Jan Honza Odvarko from comment #17)
> Created attachment 815893 [details]
> firebug-1.13.0a3.6086.xpi
> 
> Test Firebug build with a possible workaround.
> 
> Could anybody please check it out and let me know if it helps?
> 
> Thanks!
> 
> Honza

Hello, it fixes a problem for me on MS Win XP SP2 with FF 24. Very good. Thx
I hate to be the bearer of awkward news but whilst I am seeing a fix to this specific tab-switching delay issue, there appears to be either related or different issues with this Firebug build in Aurora 26.0a2 (2013-10-14) on Windows 7. The issues arose yesterday as well, when I first installed this new Firebug version, so it might be related to an Aurora issue dating back to at least October 13th. 

The two issues are:

1) Half the Firebug window is displaying normally, the top half, but the bottom half sometimes contains the "Activate Firebug for the current website" button on a blank grey section.

See attachment.

2) In between page reloads, seemingly, the active Firebug tab goes completely blank. Switching to a different tab, then back to the tab you were on, fixes the problem, but that's non-ideal obviously.

Overall though, thanks a zillion for working on this issue Honza. The Mozilla Director of Developer Tools **appears** more interested in effectively creating even more useless doubt over the already vague status of Firebug's future than fixing urgent bugs like this:

https://hacks.mozilla.org/2013/10/firefox-developer-tools-and-firebug/

I'm glad someone like yourself understands that somewhere in the world, developers are working 24x7 and need tools to rely on, so showstopper bugs are critical to fix.
Firebug 1.13.0a3.6086 within Firefox Aurora 26.0a2 (2013-10-14) on Windows 7.
(In reply to pd from comment #27)
> The two issues are:
> 
> 1) Half the Firebug window is displaying normally, the top half, but the
> bottom half sometimes contains the "Activate Firebug for the current
> website" button on a blank grey section.
> 
> See attachment.
> 
> 2) In between page reloads, seemingly, the active Firebug tab goes
> completely blank. Switching to a different tab, then back to the tab you
> were on, fixes the problem, but that's non-ideal obviously.
Thanks for the testing!

* I can't reproduce the problem on my machine.
* I tested with Firebug 1.13.0a3.6086 + Aurora 26.0a2 (2013-10-14) on Windows 7 and Windows Vista.

It doesn't look to me that this problem is related to the fix I did (slow tab switching), but I might be wrong and it would be great to double check. Do you have some baby steps describing how to reproduce the problem?

Does the problem persist if you create a new clean profile?
Does the problem persist if you install the latest stable 1.12.3 (from AMO)?

Honza
(In reply to Jan Honza Odvarko from comment #29)
> (In reply to pd from comment #27)
> > The two issues are:
> > 
> > 1) Half the Firebug window is displaying normally, the top half, but the
> > bottom half sometimes contains the "Activate Firebug for the current
> > website" button on a blank grey section.
> > 
> > See attachment.
> > 
> > 2) In between page reloads, seemingly, the active Firebug tab goes
> > completely blank. Switching to a different tab, then back to the tab you
> > were on, fixes the problem, but that's non-ideal obviously.
> Thanks for the testing!

Happy to :)

> 
> * I can't reproduce the problem on my machine.

It could perhaps be an extension conflict. I can't necessarily afford to disable extensions as this is my work machine. I'll see if I can find the time though. I actually had to install a couple of extra extensions today to try and work around the annoyance of JS minification/obfuscation. One failed miserably but that's digressing.

> * I tested with Firebug 1.13.0a3.6086 + Aurora 26.0a2 (2013-10-14) on
> Windows 7 and Windows Vista.

You touched Vista? Brave :) Sounds most likely due to an extension conflict if not an Aurora problem.

> It doesn't look to me that this problem is related to the fix I did (slow
> tab switching), but I might be wrong and it would be great to double check.
> Do you have some baby steps describing how to reproduce the problem?

I agree the slow tab switching fix doesn't seem to be causing this but it is (seemingly) still causing about 5 seconds worth of hang/high CPU when opening Firebug, I think, for the first time since a restart. Of course that's nothing compared to the tab switching lag though.

> Does the problem persist if you create a new clean profile?
> Does the problem persist if you install the latest stable 1.12.3 (from AMO)?

Wish I had a nice clean VM to test these things in. I'll see what I can do for you Honza :)
 
> Honza
>> * I can't reproduce the problem on my machine.
> 
> It could perhaps be an extension conflict.
I also can't reproduce this on my Win7 machine with Aurora 26.0a2/Nightly 27.0a1 (2013-10-15) + Firebug 1.13.0a3.6068.
So yes, it's probably an extension conflict and unrelated to this issue.

Sebastian
I have a winxp pro sp3 box 32-bit OEM on P4-HT 2.8GHz (1C2T), and it has increasing delays of like 5 minutes and up. the cursor will change to two split horizontal bars (the resizing thing) then when something happens, it happens in bursts,and then back to 5 minute delays.
I can't get xp mode to work on win7, that program is broken right now straight from the ms server.
> and it has increasing delays of like 5 minutes and up.
Are you talking about browser tab switching while Firebug is enabled and enabling Firebug for a page?
Did you try out Honza's patched version of comment 17?

Sebastian
comment 17 fixed fb for me, thanks. it wasn't necessarily tab switching, but using fb's inspector.
Ahoj Honzo,

(In reply to Jan Honza Odvarko from comment #17)
> Could anybody please check it out and let me know if it helps?

Everything works perfectly, god knows how itchy I was waiting for this issue to be resolved. At lease with a workaround. Thanks for your efforts.

p.s. I use official Firefox 24.0, running on Windows 7 x64.
Thanks to all for testing!

The workaround is now included in Firebug 1.12.4
https://blog.getfirebug.com/2013/10/21/firebug-1-12-4/
(Firebug no longer pauses the debugger when switching tabs)

Honza
Hello there,

As I see from the comments above this issue is considered to be resolved and everybody seems to be happy. Unfortunately I've been experiencing this bug with previous versions of Firefox and Firebug for a while now and with the latest FF24 and Firebug 1.12.4 it got really painful to do my work. Opening a firebug panel with an enabled script panel takes somewhere between 1 minute and infinity to load on a 8core i7 machine running Windows 7_x86_64. I haven't had the time to test it in my Slackware but as far as Windows goes - it's pretty damn slow. :(

Any ideas what may be causing this?

Regards,
Steve
I was using 1.13 attached in comment 17 and it is working nicely on my (for 1.12.x) 5-minute-wait xp box.
there won't be a 64-bit version of ff, that's been tabled.
in fact, very few browsers are 64-bit.
Steve> JSD.pause/unPause are still slow. That means that when you start/stop Firebug, you still have the big delay.

However, previously, Firebug was using this when switching from/to a Firebug-enabled tab, and that's what has been changed in the latest version of Firebug, so that tab switching is not slow anymore. The expense is that once you have Firebug enabled, all Firefox pages will probably be slightly slower.
How much slower is slightly slower?  As far as I can tell, we do not ion-compile at all when Firebug is enabled now, so if you have Firebug's open in any tab and the script panel is enabled JS in all other tabs will be _drastically_ slower.  As a simple example, http://web.mit.edu/bzbarsky/www/mandelbrot-clean.html takes about 43ms normally but with Firebug open in another tab it now takes 850ms or so.

Note that it's not just disabling ion compilation, too.  If I just disable ion but also disable Firebug that testcase is at 350ms or so.

Why is this sort of 20x performance hit on all scripts considered acceptable as a workaround for the other issue?
Flags: needinfo?(odvarko)
Flags: needinfo?(jimb)
Flags: needinfo?(jdemooij)
Flags: needinfo?(felash)
Debug mode is per-compartment. Are we really putting all compartments in debug mode?

(In reply to Boris Zbarsky [:bz] from comment #40)
> Note that it's not just disabling ion compilation, too.  If I just disable
> ion but also disable Firebug that testcase is at 350ms or so.

Wild guess, but it may be caused by an onEnterFrame hook. See bug 933557 and the plot in bug 914429.
So I did some profiling with the test extension from comment 0, using more or less the tab set proposed there.

When unpausing (which took about 660ms):

  60% of the time is spent GCing, as far as I can tell.  At least a quarter of this is
      JSScript::debugScript() calls under JSScript::markChildren.
  40% is CreateLazyScriptsForCompartment (all of it self time)

When pausing (which took about 430ms):

  100% of the time is GC; about 1/4 in JSScript::debugScript(); another 20% is in
       JSScript::markChildren() 

Let's throw more needinfo at the problem.  ;)
Flags: needinfo?(wmccloskey)
> Are we really putting all compartments in debug mode?

Yes, because Firebug is still using jsd1, so it has no per-compartment anything going on, just a global switch.  :(  See comment 5.
OS: Windows Vista → All
Hardware: x86 → All
My view is that as long as a user uses Firebug's script panel, he agrees that he can have a performance impact. There is a message warning the user about this.

This is not perfect but this is imo better than the previous situation. The best solution is to move to JSD2 but this takes time.

That said, I'm not part at all of Firebug's team and can't give any decision.
Flags: needinfo?(felash)
> My view is that as long as a user uses Firebug's script panel

The thing is, until we switched to the current pause/unpause setup it was incredibly common for people to rant about how Firefox is slow, etc and in about 90% of those cases it turned out they just had Firebug open in some random tab they had forgotten about.

I do _not_ want that repeating.  I think it was a much much larger problem than the pauses this bug is about....
I just filed bug 933882 to fix this.
Depends on: 933882
Flags: needinfo?(wmccloskey)
(In reply to Boris Zbarsky [:bz] from comment #45)
> > My view is that as long as a user uses Firebug's script panel
> 
> The thing is, until we switched to the current pause/unpause setup it was
> incredibly common for people to rant about how Firefox is slow, etc and in
> about 90% of those cases it turned out they just had Firebug open in some
> random tab they had forgotten about.
> 
> I do _not_ want that repeating.  I think it was a much much larger problem
> than the pauses this bug is about....

Yep I agree with you, it's better that the pause/unPause work fine and Firebug use it. (or JSD2 :) ).

But the new situation, because of this bug, switching from/to a Firebug-enabled tab is painfully slow as soon as you have enough tabs, and freezing the whole interface in the process. There are lots of duplicates on Firebug's bug tracker proving this.

IIRC pause/unPause were introduced especially for Firebug's use case, and to be _fast_. Faster than stopping/starting the whole debug system. This is not the case anymore, and speaking with some people, it seemed to me there is nearly no interest to improve the legacy JSD1 API, and therefore to fix this.

This leaves Firebug in the uncomfortable situation to have to choose between 2 bad solutions, until the JSD2 conversion is done. Pick your prefered one, I picked mine already :)
In case it wasn't clear what the performance impact is: simply installing Firebug 1.12.4 and enabling the script panel then closing Firebug still leaves the IonMonkey JIT permanently disabled until Firefox is restarted.  Furthermore, it introduces a huge slowdown over even the baseline JIT.  In effect, opening Firebug now enables the debug subsystem and _never_ shuts it off until the browser is shut down; all JS is always running in debug mode after that point.  The last time we had addons that caused across-the-board performance problems like this when the addon wasn't even in use, we ended up having to blacklist them.  It's an incredibly serious problem in an addon.

Basically, the "fix" to Firebug threw the baby out with the bathwater completely.  It's much, much worse than the problem it was trying to fix.

We both agree this bug needs to be fixed (and I believe it will be shortly).  What we seem to disagree on is whether the cure that was checked into Firebug is worse than the disease of this bug.  I strongly feel it is, and I hope your disagreement was based on a misapprehension of the magnitude of the problems the Firebug change causes.

I strongly suggest backing that change out and waiting for Bill to improve the performance of pause/unpause.

> it seemed to me there is nearly no interest to improve the legacy JSD1 API

Uh... Who did you talk to, exactly and about what?  When I talked to the right person in comment 42 about what the actual performance problem is here, he started working on a patch (see comment 46).
(In reply to Boris Zbarsky [:bz] from comment #48)
> Basically, the "fix" to Firebug threw the baby out with the bathwater
> completely.  It's much, much worse than the problem it was trying to fix.

I disagree. While I don't understand all the implications of the change made to Firebug it at least allows me to do my job. It was incredibly painfully slow trying to switch between tabs before. On a practical level, many of us have jobs that require using Firebug on a daily basis and from my view the cure is much better.
Slowing down all browsing is certainly a very serious problem, especially because it's a difficult one to identify. A general slowdown is much more subtle than hangs when switching tabs, but it can be worse because can be seen as a problem in Firefox and not in tabs that have Firebug enabled.

I have a few questions about this:
* What does the roadmap to JSD2 look like?
* Is bug 933882 something that can be fixed and maybe uplifted soon?
* What visual indications do users get about the overall performance impact of these new versions of Firebug?
Whiteboard: [Snappy]
> * Is bug 933882 something that can be fixed and maybe uplifted soon?

Bill?

> What visual indications do users get about the overall performance impact of these new
> versions of Firebug?

Apart from the slowness itself, none.
Flags: needinfo?(wmccloskey)
(In reply to Boris Zbarsky [:bz] from comment #51)
> > * Is bug 933882 something that can be fixed and maybe uplifted soon?
> 
> Bill?

Shu offered to work on this. I just filed the bug.
Flags: needinfo?(wmccloskey) → needinfo?(shu)
(In reply to Boris Zbarsky [:bz] from comment #51)

> 
> > What visual indications do users get about the overall performance impact of these new
> > versions of Firebug?
> 
> Apart from the slowness itself, none.

This is untrue, there is a warning message in the script panel when it's disabled:

"Warning: Enabling the Script panel slows down tab switching and Firebug activation due to a platform problem. This will be fixed with the next major Firebug version."

"platform problem" links here.

(In reply to Boris Zbarsky [:bz] from comment #48)
> [some text I basically agree with if there is work on this bug, which was not the case until today]
> 
> > it seemed to me there is nearly no interest to improve the legacy JSD1 API
> 
> Uh... Who did you talk to, exactly and about what?

I don't want to say it publicly, but I did talk to a Spidermonkey developer about this issue, both some months ago and during the summit. Jan probably did too, but I don't know more.

> When I talked to the
> right person in comment 42 about what the actual performance problem is
> here, he started working on a patch (see comment 46).

That's perfect then! I feel like the change in Firebug helped raising the awareness about this bug (which was filed 11 months ago). For this reason alone I'm glad this change has been made.
(In reply to Julien Wajsberg [:julienw] from comment #53)
> (In reply to Boris Zbarsky [:bz] from comment #51)
> > > What visual indications do users get about the overall performance impact of these new
> > > versions of Firebug?
> > 
> > Apart from the slowness itself, none.
> 
> This is untrue, there is a warning message in the script panel when it's
> disabled:
> 
> "Warning: Enabling the Script panel slows down tab switching and Firebug
> activation due to a platform problem. This will be fixed with the next major
> Firebug version."
> 
> "platform problem" links here.

But that message is intended for the old behavior, not the new one. In this case it seems like users should always be warned unless they disable the script (and restart?) since all navigation is affected.
By "always" I mean that all users should be warned at least once, since they're all affected.
Yep, probably the warning message should be more prominent.
Flags: needinfo?(jimb)
I've been needinfo'd, but I don't think I have much to add, beyond saying that I'm working on the last prerequisites for removing JSD altogether in bug 637572.
> This is untrue, there is a warning message in the script panel when it's disabled:

That message isn't talking about the performance problem that now exists, and doesn't make it clear that the problem persists even if you disable or uninstall Firebug, now does it?

> I feel like the change in Firebug helped raising the awareness about this bug

What raised awareness for me was comment 5, but today was the first chance I had to look at it.  Of course anyone else who cared could have profiled it just as well as I can....

I would really like to know whether Jan actually meant his change to have the impact it does.  Is suspect he didn't.
I always have more than 20 tabs open, and with this new patch (workaround) I don't see any problems or visible slowness. This workaround really improved the speed of my work. Please do not revert this patch, or at least make it possible to turn it on or off in the plugin settings.
WIP over in bug 933882.
Flags: needinfo?(shu)
(In reply to Boris Zbarsky [:bz] from comment #58)
> > This is untrue, there is a warning message in the script panel when it's disabled:
> 
> That message isn't talking about the performance problem that now exists,
> and doesn't make it clear that the problem persists even if you disable or
> uninstall Firebug, now does it?

Firebug 1.12.3 (having the slow-tab-switching problem) says:
Warning: Enabling the Script panel slows down tab switching and Firebug activation due to a platform problem. This will be fixed with the next major Firebug version.

Firebug 1.12.4 (removing pause/unpause code to solve the slow-tab-switching problem) says:
Warning: Enabling the Script panel slows down Firebug activation and JavaScript execution in Firefox due to a platform problem. This will be fixed with the next major Firebug version.

Of course, we are open to change the message if anyone has better suggestion.

> I would really like to know whether Jan actually meant his change to have
> the impact it does.
I was aware that the change has side effects, but we were getting so much user-reports related to it (note that this bug has been opened for almost a year) that we needed to proceed. Also, the feedback for a try-build (I made available before the release) was clearly saying that it's what users want. I don't know what else we could possibly do. What we have been waiting for all the time - is a fix for the reported platform problem.
In any case, am happy it gets the attention at this moment.

---

Even if the Firebug team is hardworking on JSD2 adoption (it's the top priority) we need this bug fixed in the meantime. Note that the last missing piece (to fully adopt JSD2 in Firebug) is support for dynamically executed JS scripts (evals, events, new Function, ...) and as JimB mentioned in comment 57 he is already working on APIs we need.

Honza
Flags: needinfo?(odvarko)
Note that people who enabled the script panel when it had the old behavior won't see the new message.

> I was aware that the change has side effects

I suppose you could describe slowing down JS execution by a factor of 20 as "side effects"....  But that seems to rather understate the problem.

> I don't know what else we could possibly do.

Well, pausing jsd when there is no Firebug open anywhere would be a good start, no?
But again, the impact of the current change is not acceptable from my point of view.  I understand where you're coming from and the problem you're trying to solve, but I don't believe we should be allowing an addon to behave the way Firebug is right now.

At a minimum, you should be clearly spelling out the extent of the performance regression Firebug causes here, and you should be alerting users who have the script panel enabled already that this past decision now has drastically different consequences.
For what it's worth, with the patch in bug 933882 unpausing jsd takes about 150ms for me on the testcase from comment 1.  Pausing takes <10ms.  (Without that patch, the times are about 600ms and 450ms respectively.)  Jan, if that lands do you plan to keep the current behavior in Firebug?
Flags: needinfo?(odvarko)
You should try with ~100 tabs, that's what I have, and with this setup switching tabs was freezing Firefox for several seconds (I'd say 3 to 5 seconds). Less than 500ms would probably be ok, less than 300ms good, less than 200ms very good ;)
(In reply to Boris Zbarsky [:bz] from comment #62)
> Note that people who enabled the script panel when it had the old behavior
The message is also displayed in the Console panel every time you start Firebug (the user can get rid of it by pressing "Got it" button). Assuming that most of JS debugging users, have the Console panel also enabled.


(In reply to Boris Zbarsky [:bz] from comment #64)
> For what it's worth, with the patch in bug 933882 unpausing jsd takes about
> 150ms for me on the testcase from comment 1.  Pausing takes <10ms.  (Without
> that patch, the times are about 600ms and 450ms respectively.)
This sounds great!

> Jan, if that lands do you plan to keep the current behavior in Firebug?
If pause/unpause is fixed (fast again) I can revert the change (fixing slow-tab-switching problem) promptly, of course.

Any chance to get a try-build with the patch?
What Firefox version would be the target for that patch?

Honza
Flags: needinfo?(odvarko)
> You should try with ~100 tabs

Loaded 100 tabs with gmail in them (which, btw, uses about 6GB of RAM with the script panel disabled, but about 11GB with it enabled, so the Firebug change is also a significant memory hog, not just a speed issue).  Unpausing jsd with the patch takes about 3000ms.  Pausing takes about 55ms.  I expect that is I used 100 tabs that are not as chock-full of script as gmail the unpausing would be much faster, of course.  And see the question in bug 933882 about why unpausing takes so much longer.

> the user can get rid of it by pressing "Got it" button

And after that it's shown the next time you start Firebug, or not?

> Any chance to get a try-build with the patch?

Sure thing.  Which architecture(s)?

> What Firefox version would be the target for that patch?

I don't know yet; see the questions I asked in that bug when I made comment 64.
Flags: needinfo?(odvarko)
(In reply to Boris Zbarsky [:bz] from comment #67)
> > the user can get rid of it by pressing "Got it" button
> 
> And after that it's shown the next time you start Firebug, or not?
It isn't shown anymore (but could reappear in the next Firebug release if necessary).

> > Any chance to get a try-build with the patch?
> Sure thing.  Which architecture(s)?
Win 32, Linux 32

Thanks!

Honza
Flags: needinfo?(odvarko)
> It isn't shown anymore 

Right, that's the problem.  The number of people who enabled the script panel in the past but didn't click this button is almost certainly slim to none.

> Win 32, Linux 32

https://tbpl.mozilla.org/?tree=Try&rev=72b2776834de
I just had a conversation with Jorge about this. We came to the conclusion that, if you're going to continue doing this, you need to do at least the following:

1) Stop the debugger when Firebug is closed.

2) Display a warning whenever the script panel is enabled that it will considerably slow down the browser. Users will not remember weeks after they dismissed a warning that Firebug is the source of their performance problems.

I'd also like:

3) Display Firebug as enabled when the debugger is running, even if the tab in the foreground is not the one being debugged.

4) Default to pausing when tabs are switched and prompt users to leave the debugger on the first time a slow tab switch is encountered.

I don't want to, but I'm going to be forced to revert your AMO listing to a version without this issue if the first two points are not addressed as soon as possible.
Filed bug 934799 on the reason unpausing is not as fast as pausing with the patch from bug 933882.
Depends on: 934799
(In reply to Kris Maglione [:kmag] from comment #70)
> I just had a conversation with Jorge about this. We came to the conclusion
> that, if you're going to continue doing this, you need to do at least the
> following:
> 
> 1) Stop the debugger when Firebug is closed.
> 
> 2) Display a warning whenever the script panel is enabled that it will
> considerably slow down the browser. Users will not remember weeks after they
> dismissed a warning that Firebug is the source of their performance problems.
> 
> I'd also like:
> 
> 3) Display Firebug as enabled when the debugger is running, even if the tab
> in the foreground is not the one being debugged.
> 
> 4) Default to pausing when tabs are switched and prompt users to leave the
> debugger on the first time a slow tab switch is encountered.
I don't understand this one.

Do you want us to back out the patch where we are avoiding calling pause/unPause
when switching Firefox tab? I hope not. In any case I hope the platform bug
will be fixed soon.

Report in Firebug issue list created:
https://code.google.com/p/fbug/issues/detail?id=6942

Honza
(In reply to Jan Honza Odvarko from comment #72)
> Do you want us to back out the patch where we are avoiding calling
> pause/unPause
> when switching Firefox tab? I hope not.

Yes, at least by default. If you want your users to have an option to switch to the current behavior, that's okay, but the default should be the tab switching slowdown, which aren't persistent.

> In any case I hope the platform bug will be fixed soon.

That may be the case, but it'll take some time for it to make it to release, and the current impact is very large to ignore in the interim. We need you to make these changes as soon as possible.
The 5 to 15 seconds that I had to wait between tab switches was the real killer, not the 15x slowdown in some arbitrary benchmark. I honestly haven't noticed any slowdowns in my day to day browsing with Honza's workaround.
Richard, past experience suggests you're an exception, not the rule.  See comment 45.  We've been here before; we're not just guessing what the effects of this change are, but have hard data from the last time Firebug had this behavior.
Boris, then all my 3 PCs with completely different configurations are all the exceptions. Btw, did people start to complain after this change? Maybe your previous experience is not actual anymore.
Denis, the "exception" is you, not the computers.

This change hasn't been live long enough for most Firebug users to have updated, run into slowness, and then started to complain about it yet.  We'd like to prevent it from getting to the point where they are, is the point.

Again, in case this wasn't clear this change takes JavaScript performance back to >5 years ago levels, if not worse.  How you can think people won't notice it, I have no idea.  Now what they _won't_ realize is that it's Firebug causing it, so the Firebug team won't hear the resulting complaints.  And we'll get them in a "general slowness" form, not a "Firebug is causing slowness" form, so they won't stand out too much until the problem is very widespread.  Which, again, is what we want to prevent.
I haven't noticed any general slowdown with Honza's change either. And compared to the annoyingly slow tab switching before, this is definitely preferable. You may or may not have users complain about slowness with his patch, but there were tons of complaints before his patch. So I don't see how switching it back to what initiated all the complaints is going to fix complaints.

I think it's good to warn users, even if it's an always active warning in the script tab. I also think it's a good idea to stop the debugger when firebug is closed in all tabs. I don't think it's a good idea to default to considerably more annoying behavior, especially if there's an active warning so they know why it's slow.

However, since it seems that it's only painfully slow for those of us that have a lot of tabs open it might be good to make it always pause and unpause when the user has a smaller number of tabs open (less than 15 or 20) and only leave it active when switching tabs for users that have more tabs open. Seems like a reasonable trade off to me.

So in summary I propose:

1) Always active warning in script tab
2) Stop debugger when Firebug is not active in any tabs
3) Always pause/unpause when switching tabs in windows that have less than some threshold (e.g. 15 or 20), but leave it active when the user has more tabs open
Honza, the pause-unpause extension crashes if you go to a site with JS (like GMail), pause, then quit immediately. Did this always happen?

As for everyone here commenting that Honza's fix is perfectly fine, as bz says, it really isn't. We're also not asking you to live with the long GC pause times either and are actively pursuing fixes in bugs 934799 and 933882 for performance to be acceptable.
(In reply to Shu-yu Guo [:shu] from comment #79)

> As for everyone here commenting that Honza's fix is perfectly fine, as bz
> says, it really isn't. We're also not asking you to live with the long GC
> pause times either and are actively pursuing fixes in bugs 934799 and 933882
> for performance to be acceptable.

I don't think anyone things it's perfectly fine. But it is what it is and many of us still need to be able to function with Firebug from day to day for our jobs. Honzas fix allows that to happen. It's not perfectly fine, but until those bugs are fixed it keeps us in business. That's all.
Depends on: 935228
(In reply to Jorge Villalobos [:jorgev] from comment #73)
> (In reply to Jan Honza Odvarko from comment #72)
> > Do you want us to back out the patch where we are avoiding calling
> > pause/unPause
> > when switching Firefox tab? I hope not.
> 
> Yes, at least by default. If you want your users to have an option to switch
> to the current behavior, that's okay, but the default should be the tab
> switching slowdown, which aren't persistent.

Because so far the Firebug Working Group got no negative comment on the patch but only positive feedback, it doesn't make sense for us to provide an option for the users allowing to switch to the previous behavior.

> > In any case I hope the platform bug will be fixed soon.
> 
> That may be the case, but it'll take some time for it to make it to release,
> and the current impact is very large to ignore in the interim.

Well, the impact of the platform bug was ignored before. See the date when Honza reported this bug and the long pause after comment 3.

> We need you to make these changes as soon as possible.

Changes on our side will happen in https://code.google.com/p/fbug/issues/detail?id=6942. These changes will at least include point 1 and 2.

If possible the changes on your side should make it into beta, so the time span for the platform fix(es) is just a few weeks.

(In reply to Boris Zbarsky [:bz] from comment #69)
> > Win 32, Linux 32
> 
> https://tbpl.mozilla.org/?tree=Try&rev=72b2776834de

(In reply to Shu-yu Guo [:shu] from comment #79)
> Honza, the pause-unpause extension crashes if you go to a site with JS (like
> GMail), pause, then quit immediately. Did this always happen?

I tried the test build compared to the currently Nightly with Honza's test extension and the steps of comment 0 on Win7 and these are my results:

Try-build:
pause: 22, unpause: 508

Nightly (2013-11-05):
pause: 2558, unpause: 1908

So there's a big speed difference. Unfortunately the try-build crashes for me reproducibly with the steps Shu mentioned (but sometimes also already while pausing/unpausing):
https://crash-stats.mozilla.com/report/index/7516d037-8e1d-4ae6-b5e7-6d9712131106
https://crash-stats.mozilla.com/report/index/3b7ae440-9491-4fea-b454-2bbc82131106
https://crash-stats.mozilla.com/report/index/ae35dad8-dc7f-432e-9ded-63ba82131106

The currently Nightly doesn't.

Sebastian
(In reply to Kris Maglione [:kmag] from comment #70)
> I just had a conversation with Jorge about this. We came to the conclusion
> that, if you're going to continue doing this, you need to do at least the
> following:
> 
> 1) Stop the debugger when Firebug is closed.
> 
> 2) Display a warning whenever the script panel is enabled that it will
> considerably slow down the browser. Users will not remember weeks after they
> dismissed a warning that Firebug is the source of their performance problems.
I am already working on these two.

Kris marked #3 and #4 points as "I'd also like", so they don't have to be
included in 1.12.5 (the next Firebug release).

The entire Firebug team has been discussing this issue yesterday and we agreed
that critical is to have this reported bug fixed and patch ported into beta if
possible. In such case it'll move to release on week of December 10. 

Honza
> so far the Firebug Working Group got no negative comment on the patch but only positive
> feedback

Have you actually read what I wrote so far in this bug?  The whole problem is people not realizing the Firebug is what makes their browser slow.  If they don't realize that, they're not likely to complain to the Firebug Working Group, now are they?

> Well, the impact of the platform bug was ignored before.

The impact of this bug as described in comment 2 is just not that bad compared to other issues people needed to work on, unfortunately.  The numbers reported there are at least an order of magnitude lower than the numbers in the later comments here, and while they're definitely not great they don't rise to the "nuke performance across the board to avoid this" level.  Whereas I can see how a 2-second pause time on tab switch would!

I can't speak to whatever discussions you had with people in private, of course, and I do agree it would have been better to focus on this more earlier, but the urgency just wasn't there given the information provided in this bug.

Also note that the lazy script issues of bug 934799 are very recent; much more recent than comment 3...  So it is in fact quite likely that performance here wasn't nearly as bad last year as it is now.  Lazy scripts were added in Firefox 24; did you guys see an increase in complaints at that point?

> Unfortunately the try-build crashes for me reproducibly

Right, the try build uses the then-current version of Shu's patch, which is somewhat buggy.
(In reply to Boris Zbarsky [:bz] from comment #83)

> Also note that the lazy script issues of bug 934799 are very recent; much
> more recent than comment 3...  So it is in fact quite likely that
> performance here wasn't nearly as bad last year as it is now.  Lazy scripts
> were added in Firefox 24; did you guys see an increase in complaints at that
> point?

One bug was reported for Firefox 24 [1] but others were reported before [2] [3] [4].

In [1] users are actually reporting a massive slowdown though.

[1] http://code.google.com/p/fbug/issues/detail?id=6688
[2] http://code.google.com/p/fbug/issues/detail?id=6086
[3] http://code.google.com/p/fbug/issues/detail?id=6181
[4] http://code.google.com/p/fbug/issues/detail?id=6384
> In [1] users are actually reporting a massive slowdown though.

_That_ would have been very useful information to have at the time, in a separate bug report from this one; would have gotten eyes on it a lot sooner.  :(

Please do not hesitate to file bugs like that in the future and cc me on them....
(In reply to Boris Zbarsky [:bz] from comment #83)
> > so far the Firebug Working Group got no negative comment on the patch but only positive
> > feedback
> 
> Have you actually read what I wrote so far in this bug?

I did. I may add "from Firebug users" to my statement.

> The whole problem is people not realizing the Firebug is what makes their browser slow.

To be precise, it's JSD causing the slowdown.

> If they don't realize that, they're not likely to complain to the Firebug
> Working Group, now are they?

We already try to clarify the circumstances in the messages we display in the Script and the Console panel.

> > Unfortunately the try-build crashes for me reproducibly
> 
> Right, the try build uses the then-current version of Shu's patch, which is
> somewhat buggy.

It would be great you could create another try-build as soon as Shu sorted out the problems.

(In reply to Julien Wajsberg [:julienw] from comment #84)
> (In reply to Boris Zbarsky [:bz] from comment #83)
> 
> > Also note that the lazy script issues of bug 934799 are very recent; much
> > more recent than comment 3...  So it is in fact quite likely that
> > performance here wasn't nearly as bad last year as it is now.  Lazy scripts
> > were added in Firefox 24; did you guys see an increase in complaints at that
> > point?
> 
> One bug was reported for Firefox 24 [1] but others were reported before [2]
> [3] [4].
> 
> In [1] users are actually reporting a massive slowdown though.
> 
> [1] http://code.google.com/p/fbug/issues/detail?id=6688
> [2] http://code.google.com/p/fbug/issues/detail?id=6086
> [3] http://code.google.com/p/fbug/issues/detail?id=6181
> [4] http://code.google.com/p/fbug/issues/detail?id=6384

Right, that reflects what I posted in comment 2. The problem was there for long but got way worse with the latest Firefox versions.

Sebastian
> I may add "from Firebug users" to my statement.

That doesn't change your statement significantly; of course only Firebug users would be impacted by Firebug's behavior.

> To be precise, it's JSD causing the slowdown.

JSD is a debugger.  All debuggers cause a slowdown in the debuggee when I've tested; that includes C++ debuggers.  Firebug is what _permanently_ enables the debugger even when the user is not trying to debug anything, though.

> We already try to clarify the circumstances in the messages we display in the Script
> and the Console panel.

Sure.  But until you address Kris' point 1, that's not nearly enough.  And again, in the past even in spite of the messaging in these panels Firebug users assumed that since they couldn't see Firebug (because it was in some other tab) it couldn't be causing the performance problem.  Anyway, addressing points 1 and 2 will help a lot here.

> It would be great you could create another try-build

Sure thing.  https://tbpl.mozilla.org/?tree=Try&rev=b60992ed8d3f

> The problem was there for long but got way worse with the latest Firefox versions.

Comment 2 predates Firefox 24 by nearly a year.  No one ever brought up the new regression Firefox 24 introduced in a bugzilla bug report until I saw it in the profiles, as far as I can tell...
This is a try build closer to what the final fixes look like. As you can see, there are still some mochitest failures, but less crashy.

https://tbpl.mozilla.org/?tree=Try&rev=6bc541282238
(In reply to Shu-yu Guo [:shu] from comment #88)
> This is a try build closer to what the final fixes look like. As you can
> see, there are still some mochitest failures, but less crashy.
> 
> https://tbpl.mozilla.org/?tree=Try&rev=6bc541282238

I tried the test build with the test extension on a new Win8.1 machine now and didn't see any crash so far while the performance was even better than before breaking the first pausing/unpausing down to a few milliseconds and repeated pausing/unpausing to just one millisecond. Wow!

This time I also tried out Firebug 1.12.3 (which doesn't include the workaround) with this build and it's working perfectly fast again. So thanks a lot, Shu!

(In reply to Boris Zbarsky [:bz] from comment #87)
> Anyway, addressing points 1 and 2 will help a lot here.

Honza is already working on it.

Sebastian
(In reply to Justin Warkentin from comment #49)
> (In reply to Boris Zbarsky [:bz] from comment #48)
> > Basically, the "fix" to Firebug threw the baby out with the bathwater
> > completely.  It's much, much worse than the problem it was trying to fix.
> 
> I disagree. While I don't understand all the implications of the change made
> to Firebug it at least allows me to do my job. It was incredibly painfully
> slow trying to switch between tabs before. On a practical level, many of us
> have jobs that require using Firebug on a daily basis and from my view the
> cure is much better.

Absolutely +1. This bug is old news for an Aurora + Firebug user like myself. Having encountered this bug seemingly several weeks before others, what do I do, just switch to a Beta or 'gold' release? Unfortunately it's not that easy so once a serious bug like this is encountered, I can (barely) put up with it for a couple of weeks but beyond that, an interim pragmatic solution such as that applied by Seb and Honza and co, is incredibly welcome, especially since I can spend hours just fiddling with CSS and never touch any JS debugging.

I personally thank Seb and Honza for caring and welcome others to the task at hand :) I haven't yet got through all the bugmail on this one so who knows, there may be a solution near the end.
(In reply to Jorge Villalobos [:jorgev] from comment #50)
> Slowing down all browsing is certainly a very serious problem, 

I agree but this is not something that I can say was a problem, perhaps because the legendary Firebug devs implemented a workaround whereby the "Clear Activation List" option no longer required confirmation every time it was used. I therefore have got into the habit of applying that function if there's any slowdown in - AFAIK - Firebug-enabled tabs. This might sound contradictory to the assessment of Firebug using 'global' debugging, but I don't really notice a general slowdown in non Firebug-enabled tabs. This is using:

26.0a2 (2013-10-28) (and the last 2-4 weeks of Aurora builds) 
and
Firebug 1.13.0a4

> especially because it's a difficult one to identify. A general slowdown is much more
> subtle than hangs when switching tabs, but it can be worse because can be
> seen as a problem in Firefox and not in tabs that have Firebug enabled.
> 
> I have a few questions about this:
> * What does the roadmap to JSD2 look like?
> * Is bug 933882 something that can be fixed and maybe uplifted soon?
> * What visual indications do users get about the overall performance impact
> of these new versions of Firebug?

Since the release of the Firebug version with the Script panel disabled, the only interruption I notice is that the browser hangs when first starting up Firebug for the day. This last for approximately 3-5 seconds and is visually represented by (Not Responding) appearing in the titlebar. 

Personally this is nothing compared to the 45 second GC I experienced (on my non-work machine) yesterday and at once per session is pretty much irrelevant to me compared to the tab-switching impact (which visually was the same but of course happened much more frequently).
> Having encountered this bug seemingly several weeks before others, what do I do

You file it?  _This_ bug is over a year old, and no one bothered to tell us that there was a recent more serious problem!
(In reply to Jorge Villalobos [:jorgev] from comment #73)
> (In reply to Jan Honza Odvarko from comment #72)
> > Do you want us to back out the patch where we are avoiding calling
> > pause/unPause
> > when switching Firefox tab? I hope not.
> 
> Yes, at least by default. If you want your users to have an option to switch
> to the current behavior, that's okay, but the default should be the tab
> switching slowdown, which aren't persistent.

You want Jan to force user's like me to experience excessive tab-switching slowdowns? That's ridiculous. It makes a mockery of Mozilla's pro-developer propaganda.

> 
> > In any case I hope the platform bug will be fixed soon.
> 
> That may be the case, but it'll take some time for it to make it to release,
> and the current impact is very large to ignore in the interim. We need you
> to make these changes as soon as possible.

I think you are misunderstanding the problem. The Firebug version with the disable-Script-panel fix *does not* slow down Firefox 26.0a2 (2013-10-28) plus at least three weeks back, in my experience, simple as that. So why revert the fix and force users to experience to tab switching freeze/super-slowness?
pd, I actually maybe you guys are misunderstanding. I just tried running sunspider on a fresh profile and recorded the results (~340ms), then went to AMO and installed Firebug, turned the script panel on in Firebug, and opened a new tab and re-ran Sunspider without enabling Firebug on that tab. It took ~4500ms. So yes, this is a valid concern the devs are bringing up. It might cause confusion or worse, unless Firebug at least warns the user appropriately about the effects of the script panel until the underlying problem is actually solved.
(In reply to Thomas from comment #94)
> pd, I actually maybe you guys are misunderstanding. I just tried running
> sunspider on a fresh profile and recorded the results (~340ms), then went to
> AMO and installed Firebug, turned the script panel on in Firebug, and opened
> a new tab and re-ran Sunspider without enabling Firebug on that tab. It took
> ~4500ms. So yes, this is a valid concern the devs are bringing up. It might
> cause confusion or worse, unless Firebug at least warns the user
> appropriately about the effects of the script panel until the underlying
> problem is actually solved.

Hi Thomas

Your evidence is yet more synthetic non-user experience. Do you use Firebug daily? Those who do invariably do not see a problem. We're happy to leave the Script tab off until there is a more permanent solution. 

The only confusion is why Mozilla developers are ignoring the real-world feedback of Firebug users.
I'm not saying Firefox's reaction is the right way to solve it, I'm just saying the problem exists. I don't think every single Firebug user has been keeping up with this issue, have they? There will probably be a number of them who only notice that tab-switching suddenly is fast, but won't immediately notice that JS is much slower across the browser. I'm sure not all of them turn off the script tab after they're done with it, either. It's not a trivial thing, let's not turn into a mud-slinging match full of hyperbole.
(In reply to Thomas from comment #96)
> I'm not saying Firefox's reaction is the right way to solve it, I'm just
> saying the problem exists. I don't think every single Firebug user has been
> keeping up with this issue, have they?

Well here is where we have a problem: 

1) Mozilla (Boris largely, it seems) is assuming that Firebug users are/will complaining to Mozilla that Firefox is slow

2) Firebug users who have experienced the big tab-switching slowdown (2-4 weeks ago) are generally all happy with Jan's fix

In 1) there appears to be an assumption that the issue is effecting Firebug users who in turn complain to Mozilla. In 2) *actual* *real* Firebug users, who have verified Jan's fix in *daily* active use, are as happy (or as happy as can be with a workaround as opposed to a fix).

I'm not sure if there's a disconnect here in terms of communication but AFAIK Firebug users communicate via a Google Group more than any others means and there's plenty of evidence of the issue being handled perfectly well.

https://groups.google.com/forum/#!topic/firebug/ASoMXTb20FM
https://groups.google.com/forum/#!topic/firebug/At1cJv2ndFo
https://groups.google.com/forum/#!topic/firebug/X7-L4fTuM1Y
https://groups.google.com/forum/#!topic/firebug/lD1sMFOPB_s

You can see that this issue goes back as far as, at least, August 20th in Aurora. You can also see from those links above that the dedicated (almost) lone-ranger Firebug developers (Seb, Jan etc) spend a lot of time liaising and resolving developer issues in that group. 

Forcing the previous buggy behaviour back on Firebug users who are happy with the present workaround is nothing short of bullying them, at best.

> There will probably be a number of
> them who only notice that tab-switching suddenly is fast, but won't
> immediately notice that JS is much slower across the browser. 

That simply is not true in a real-world situation. Additionally you are talking about developers, not uneducated average users. Maybe the Mozillians think they know more about front-end website development than web developers because they understand the internals of Firefox where most web developers probably don't? Is that possible? If so, that's arrogant and not reflected in reality.

You have to remember that to use Firebug you have to be very battle-hardened because Mozilla has treated Firebug with disdain for years. There was the multi-year situation where Mozilla kept blaming Firebug for memory bloat and performance issues, pre-MemShrink, when it turned out that it was an internal Firefox bug:

http://blog.kylehuey.com/post/21892343371/fixing-the-memory-leak

Then there was the decision to create native DevTools and only assign just one paid developer (Honza) to Firebug. I really have to wonder if Firebug would have ever been created if it wasn't for it being a one-person passion project in the first place. The Mozilla bureaucracy has taken over and largely dismissed Firebug as just another add-on, despite their hacks.mozilla propaganda to the contrary.



> I'm sure not
> all of them turn off the script tab after they're done with it, either. 

But equally you're not sure they don't. Let's be realistic, do we have telemetry about how people use Firebug? If not then we're all just guessing. You're guessing and assumption and so am I.

> It's not a trivial thing, 

Web Developers are supposed to one of Mozilla closest allies, aren't they? Therefore treating them with respect should be far from a trivial thing, I agree.

> let's not turn into a mud-slinging match full of hyperbole.

It already has become somewhat of a mud-slinging match because some people are not considering the real-world user input. I know bugzilla is not meant to be a forum (though why not is still debatable IMHO) but when a bug becomes a discussion, as this bug did many comments ago, surely people should not be denied a right of reply? That is, unless Mozilla meritocracy approach puts internal developers ahead of web developers.
I just think you're blowing this WAY out of proportion, not to mention reading my post in a snarky and vindictive tone. So I'll just leave it at this: no one will be stopping you from downloading a fix that's not on AMO but on the main Firebug site, and so any stance Mozilla takes on this will not affect us at all. In the meantime we finally have Mozilla working on the real issues, so I'm happy. You can champion your cause now, and call me and others arrogant without considering your own arrogance. It's clear you need to be right about this, so be right about it.
(In reply to Thomas from comment #98)
> I just think you're blowing this WAY out of proportion, not to mention
> reading my post in a snarky and vindictive tone. So I'll just leave it at
> this: no one will be stopping you from downloading a fix that's not on AMO
> but on the main Firebug site, and so any stance Mozilla takes on this will
> not affect us at all. In the meantime we finally have Mozilla working on the
> real issues, so I'm happy. You can champion your cause now, and call me and
> others arrogant without considering your own arrogance. It's clear you need
> to be right about this, so be right about it.

I don't need to be right, I need Firebug users to be treated as first-class Mozillians. Excluding a version of Firebug from AMO that includes the disable-Script-panel workaround does not treat Firebug users as first-class citizens. 

I'm not trying to be 'right' any more than yourself or others are, just want fair equal treatment. Mozilla has chosen to deny Firebug resources and is now paying the price as Microsoft's latest developer tools are now far better than either Firebug or DevTools. So we now have a situation where all Firefox web developers, be it Firebug or DevTools users (or both) are handicapped by the one browser developer who claims to support web standards as it's raison de 'etre (pardon my flawed French). If it is arrogant to want that situation addressed then I guess I'm arrogant.

This bug should be about fixing an issue for Firebug users, not making our lives harder. If I'm being arrogant in sticking up for Firebug users, then listen to Seb, Richard, bal3bel, Justin, Jan, DaGizz, Peter, Denis, Johan or any of the other happy Firebug users in the Google Group.

I'll unsubscribe from this bug now before everyone sends more bad karma towards me :) Best of luck to everyone.
While I'm a bit embarrassed about pd defending the Firebug Working Group that strongly, I have to say that this discussion has escalated too far. This is not the right place for this discussion.
So please let's focus again on fixing this problem.

Shu's try-build from comment 88 already looks very promising. I also tried it on the other (Win7) machine now and it is very performant for me. It's a bit slower than on my new PC, but it also just takes some milliseconds to pause/unpause. Also I didn't see any crashes there.
So again, it would be great if that fix could be ported to Firefox 26.

Sebastian
(In reply to pd from comment #97)
> You have to remember that to use Firebug you have to be very battle-hardened
> because Mozilla has treated Firebug with disdain for years. There was the
> multi-year situation where Mozilla kept blaming Firebug for memory bloat and
> performance issues, pre-MemShrink, when it turned out that it was an
> internal Firefox bug:
> 
> http://blog.kylehuey.com/post/21892343371/fixing-the-memory-leak
o_0 wat?

There are lots of points I disagree with in this discussion and I was planning on not answering, but this one shouldn't remain unanswered.

The fix Kyle Huey describes is not a fix of Firefox internals. It's a trick that enables GC to happen even when facing misbehaving (leaky) addons.
Ideally, all addons would take care of their memory and leaks. Reality is very different; addons leak, some very badly (I don't know nor care where Firebug stands).
This reality forced Firefox to implement the trick. And they did at the level they can act at, that is Firefox internals. Firefox internals is where the fix happened, but it's far from being the place where the problem is rooted (which is in each leaky addon, past present and future) - pun intended :-)

Sorry for the noise. Happy to continue this discussion in private emails if something I wrote isn't clear.
(In reply to David Bruant from comment #101)
> The fix Kyle Huey describes is not a fix of Firefox internals. It's a trick
> that enables GC to happen even when facing misbehaving (leaky) addons.
> Ideally, all addons would take care of their memory and leaks. Reality is
> very different; addons leak, some very badly (I don't know nor care where
> Firebug stands).

Yes. Firebug happens to be fairly leaky without Huey's fix. And it might not be Firebug's fault at all; it might only be JSD, or it might be Firebug's specific use of JSD. At any rate, our leak tracking tools turned out to just not be good enough to track down all the leaks, though Honza's heroics *did* fix a number of them. Various people spent quite a bit of time tracking that stuff down, but when the Huey fix came along, we decided it wasn't worth the effort since the symptoms were resolved and JSD is deprecated.

I won't respond to everything in pd's comment I disagree with here, though I might reply to a mailing list post. But one additional thing could use clarification: Firebug is a special addon, and is treated differently. We've put quite a bit of effort into maintaining JSD for Firebug's use alone, because Firebug was critical to our developer community. Even with today's builtin tools, it's important enough that we won't drop JSD until Firebug no longer needs it. JSD was written against a different Gecko and Spidermonkey than we have today, so there's an impedance mismatch that we keep papering over.

(On a human side, Honza is awesome, as are the other Firebug developers. And they arguably deserve more support than most addon developers, partly because they do so much legwork for things that may end up being core bugs. But that's my personal opinion.)

Sorry for the noise in this bug, but I was worried that people were unaware of JSD's current status.
Whatever poor technical decisions were made on which side is all spilled milk under the bridge by me. I am embarrassed that we sat on this bug for so long, however.

Here's the latest try with all the fixes, and it finally looks all green. This bug has become a tracking bug for the bugs in this push, so I'll close this bug when we land them.

Firebug devs, could you test the builds in the try push? https://tbpl.mozilla.org/?tree=Try&rev=7cfc65ac5686
Unfortunately the test build from comment 103 breaks the debugger and causes crashes[1] when double-pausing. The build from comment 88 didn't have these problems. Tested again on my Win7 machine.

Sebastian

[1] https://crash-stats.mozilla.com/report/index/e596c2ca-c5c6-4802-91d6-264252131108
I am attaching test Firebug build (version number: firebug-1.12.4.6942).

More detailed info about the changes is in related Firebug issue report:
http://code.google.com/p/fbug/issues/detail?id=6942

This version implements features suggested by Kris (in comment 70) and some other little improvements:

1) JSD is deactivated (jsd.off) when the last Firebug is closed (JSD is disabled after 1000ms timeout). It's re-activated as soon as the user opens Firebug again (and the Script panel is enabled).

2) The warning message about JSD slowing down Firefox is always displayed (in the Console and in disabled Script panel) and has been also updated to:
"Warning: Enabling the Script panel causes a Firefox slow-down due to a platform bug. This will be fixed with the next major Firefox and Firebug versions.
(please suggest a new wording in the 6942 issue report, if you think it needs to be yet improved)

3) The Start button tooltip (see what is the start button here: http://www.softwareishard.com/blog/firebug/firebug-tip-the-start-button/)
has been also updated and it now always shows an info about number of active Firebugs and also info about Firebug being active in a background tab (if any).

4) The start button icon has now three states:
- Firebug is completely deactivated (gray icon)
- Firebug is active on the current page (colorful icon)
- Firebug is not active on the current page, but active in a background tab (half-colorful icon)

5) Firebug can be completely deactivated by executing "Clear Activation List" menu item from the Start button context menu. This action closes all Firebug instances in all browser windows, which also ensures that JSD is deactivated (off).

---

Any feedback, mainly related to JS execution performance testing (verifying that JSD is off when it's supposed to be off) is welcome!

Honza
(In reply to Sebastian Zartner from comment #104)
> Unfortunately the test build from comment 103 breaks the debugger and causes
> crashes[1] when double-pausing. The build from comment 88 didn't have these
> problems. Tested again on my Win7 machine.
> 
> Sebastian
> 
> [1]
> https://crash-stats.mozilla.com/report/index/e596c2ca-c5c6-4802-91d6-
> 264252131108

I can't reproduce a crash when double pausing. I got a separate crash when browsing a site with JS like GMail, but after I fixed that I didn't independently see a double pause/unpause crash.
(In reply to Shu-yu Guo [:shu] from comment #106)
> (In reply to Sebastian Zartner from comment #104)
> > Unfortunately the test build from comment 103 breaks the debugger and causes
> > crashes[1] when double-pausing. The build from comment 88 didn't have these
> > problems. Tested again on my Win7 machine.
> > 
> > Sebastian
> > 
> > [1]
> > https://crash-stats.mozilla.com/report/index/e596c2ca-c5c6-4802-91d6-
> > 264252131108
> 
> I can't reproduce a crash when double pausing. I got a separate crash when
> browsing a site with JS like GMail, but after I fixed that I didn't
> independently see a double pause/unpause crash.

Clearly reproducible on my Win8.1 PC.[1]

My steps:
1. Installed Honza's test extension
2. Opened all the sites he mentioned (gmail.com 5x, Etherpad 1x, github.com 2x)
3. Reloaded all tabs at once via right-click on a Tab > Reload All Tabs
4. Right-clicked into the page (while some tabs were still loading) and chose "Pause" from the context menu 2x

Though the worse thing is that debugging is not working with that version.

Steps for this:
1. Install Firebug 1.12.3[2]
2. Open Firebug on https://getfirebug.com/tests/manual/console/joes-original/test.html
3. Enable and switch to the Script panel
4. Reload the page
5. Click the "Debugger Deep" button on the page

=> The script execution should stop at line 232 of test.html, though nothing happens.
This works fine with the current Nightly (2013-11-08) and with your previous try-build.

Sebastian

[1] https://crash-stats.mozilla.com/report/index/679353cc-cde7-4de0-8bb5-2301f2131108
[2] https://getfirebug.com/releases/firebug/1.12/firebug-1.12.3.xpi
Thanks for the steps, Sebastian. I see them now and am investigating.
(In reply to Sebastian Zartner from comment #107)

> Clearly reproducible on my Win8.1 PC.[1]
> 
> My steps:
> 1. Installed Honza's test extension
> 2. Opened all the sites he mentioned (gmail.com 5x, Etherpad 1x, github.com
> 2x)
> 3. Reloaded all tabs at once via right-click on a Tab > Reload All Tabs
> 4. Right-clicked into the page (while some tabs were still loading) and
> chose "Pause" from the context menu 2x
> 

Fixed, hopefully. Pretty sure was due to an existing bug in firing onTrap handlers.

> Though the worse thing is that debugging is not working with that version.
> 
> Steps for this:
> 1. Install Firebug 1.12.3[2]
> 2. Open Firebug on
> https://getfirebug.com/tests/manual/console/joes-original/test.html
> 3. Enable and switch to the Script panel
> 4. Reload the page
> 5. Click the "Debugger Deep" button on the page
> 
> => The script execution should stop at line 232 of test.html, though nothing
> happens.
> This works fine with the current Nightly (2013-11-08) and with your previous
> try-build.
> 

Fixed.

Could you try the try builds below (when they finish)? https://tbpl.mozilla.org/?tree=Try&rev=bfec557f0a91
Debugging works fine for me now without crashes. Thanks Shu!

Sebastian
Flags: needinfo?(jdemooij)
The bugs this one is depending on were all marked as "Target Milestone: mozilla28".
As expressed earlier this should be released earlier. When Firefox 28 is released the Firebug Working Group will probably already have its JSD2 version out. So that'd be too late.

Sebastian
(In reply to Sebastian Zartner from comment #111)
> The bugs this one is depending on were all marked as "Target Milestone:
> mozilla28".
> As expressed earlier this should be released earlier. When Firefox 28 is
> released the Firebug Working Group will probably already have its JSD2
> version out. So that'd be too late.
> 
> Sebastian

I will try to backport once the patches stick. The change in GC behavior has caused a spike of out-of-memory failures on our tree, and it's highly possible that these patches will have to be reverted until we can fix the underlying OOMs. :(

See bug 937997.
Sebastian, the "target milestone" field is always set to the version that trunk is when the patch landed.  It has nothing to do with where we plan to backport to; that's tracked via the backport flags.
Thanks for the clarification, Boris.

(In reply to Shu-yu Guo [:shu] from comment #112)
> (In reply to Sebastian Zartner from comment #111)
> > The bugs this one is depending on were all marked as "Target Milestone:
> > mozilla28".
> > As expressed earlier this should be released earlier. When Firefox 28 is
> > released the Firebug Working Group will probably already have its JSD2
> > version out. So that'd be too late.
> > 
> > Sebastian
> 
> I will try to backport once the patches stick. The change in GC behavior has
> caused a spike of out-of-memory failures on our tree, and it's highly
> possible that these patches will have to be reverted until we can fix the
> underlying OOMs. :(
> 
> See bug 937997.

I'll follow the bug, thanks.

Sebastian
Firebug 1.12.5 has bee uploaded on AMO and is awaiting a review.
The version implements logic described in comment #105
(suggestions from comment #70).

Honza
As a normal Firefox and Firebug user, I look forward to the fix being released as the lag from tab switching is incredibly painful and costly. This issue is the only reason I created an account here. I find myself using Chrome more often the past several months as a direct result to this issue.

-Jason
(In reply to Jason from comment #116)
> As a normal Firefox and Firebug user, I look forward to the fix being
> released as the lag from tab switching is incredibly painful and costly.
> This issue is the only reason I created an account here. I find myself using
> Chrome more often the past several months as a direct result to this issue.
> 
> -Jason

Thanks for your comment! Part of the fix is in nightly, but the change in GC behavior has made some latent bugs very visible, and until we fix those I don't feel confident backporting the fix. Once we fix those bugs, however, I will backport the patches.
(In reply to Shu-yu Guo [:shu] from comment #117)
> Thanks for your comment! Part of the fix is in nightly, but the change in GC
> behavior has made some latent bugs very visible, and until we fix those I
> don't feel confident backporting the fix. Once we fix those bugs, however, I
> will backport the patches.

(For those keeping score, bug 941787 has just been fixed, thanks to Shu's dogged perseverance.)
(In reply to Boris Zbarsky [:bz] from comment #3)
> I believe the problem is that unpausing involves throwing away jitcode and
> the like, no?  And doing that for all compartments, because the jsd api
> doesn't let you debug per-compartment sanely...

(In reply to Shu-yu Guo [:shu] from comment #117)
> (In reply to Jason from comment #116)
> > As a normal Firefox and Firebug user, I look forward to the fix being
> > released as the lag from tab switching is incredibly painful and costly.
> > This issue is the only reason I created an account here. I find myself using
> > Chrome more often the past several months as a direct result to this issue.
> > 
> > -Jason
> 
> Thanks for your comment! Part of the fix is in nightly, but the change in GC
> behavior has made some latent bugs very visible, and until we fix those I
> don't feel confident backporting the fix. Once we fix those bugs, however, I
> will backport the patches.

(In reply to Jim Blandy :jimb from comment #118)
> (In reply to Shu-yu Guo [:shu] from comment #117)
> > Thanks for your comment! Part of the fix is in nightly, but the change in GC
> > behavior has made some latent bugs very visible, and until we fix those I
> > don't feel confident backporting the fix. Once we fix those bugs, however, I
> > will backport the patches.
> 
> (For those keeping score, bug 941787 has just been fixed, thanks to Shu's
> dogged perseverance.)
blocking-b2g: --- → koi?
I don't see a reason included for the nomination for b2g or why this is applicable to b2g, so I'm clearing the nom.
blocking-b2g: koi? → ---
I have nominated the following bugs for uplift to aurora and beta:

 - bug 936143
 - bug 935228
 - bug 933882
 - bug 935470 
 - bug 942346
 - bug 934799
Tracking this meta bug to ensure the bugs listed in comment 121 get landed to Aurora in time for the first 27.0 beta build and get QA verification with time to spare.
status-firefox27: --- → affected
tracking-firefox27: --- → +
Keywords: verifyme
Shu, you've had approval for a few days now. Are you going to uplift these patches to Aurora soon?
Flags: needinfo?(shu)
Calling this a feature for QA purposes.
Keywords: feature
Target Milestone: --- → mozilla27
Flags: needinfo?(shu)
Hi Guys,

I just made an account here because though this bug isn't directly affecting me, but shouldn't there be a cross mark to turn off the warning, the yellow warning is permanent and it seems odd and irritating for folks not really affected by it to keep having to see it all the time. I am sorry if i missed an option to turn off warnings, is there one?
 
Thanks!
Everyone who sees the warning is affected by it. That's why it's there.
Although, for what it's worth, I wouldn't be opposed to allowing users to dismiss it for the span of a debugging session.
Thats not entirely correct, if i understand this correctly, only if you are using multiple tabs is when its an issue, what about folks who just use one tab for development and have to keep looking at it. It seems like its a notice, which after its served its purpose has no use to keep popping up.
If you use only one tab, you would never experience _this_ bug (which is about slow tab switching), but you would in fact experience the performance degradation from Firebug turning off the JIT.  Though maybe that's a non-issue now that it reenables it when you close Firebug....
I don't think it's a non-issue, just less of an issue. It re-enables it when you close Firebug, but not when you switch to a tab without Firebug if you haven't closed it first.
blocking-b2g: --- → 1.5?
 (In reply to Lukas Blakk [:lsblakk] from comment #122)
> Tracking this meta bug to ensure the bugs listed in comment 121 get landed
> to Aurora in time for the first 27.0 beta build and get QA verification with
> time to spare.

Given, bugs mentioned in comment #121 are all closed in preparation for release in Fx27, I am marking this meta bug fixed. Also, NI :tracy to make sure this is on QA's radar for verification..
status-firefox27: affected → fixed
Flags: needinfo?(twalker)
Using the STR's from the fbug report

1. Open Firebug on https://getfirebug.com
2. Enable the Script panel
3. Reload the page
4. Open a second browser tab and go to http://google.com
5. Switch back to the previous browser tab

I am unable to reproduce slow tab switching with Fx27beta6
status-firefox27: fixed → verified
Flags: needinfo?(twalker)
Keywords: verifyme
Tracy, were you using a Firebug without the workaround they added for this bug?
Flags: needinfo?(twalker)
Boris, version 1.12.5
Flags: needinfo?(twalker)
just read their release notes. 1.12.5 should have only informed users why tab switching was slow.  So I believe I tested with a version that can safely verify the Fx side fix.
Probably better to check with 1.12.3 to be sure...
Verified with 1.12.3 on Win 8.1 with Fx27beta6
Awesome, thank you!
Has this feature been implemented, then? Can we close the bug?
blocking-b2g: 1.5? → ---
status-firefox27: verified → ---
tracking-firefox27: + → ---
Target Milestone: mozilla27 → ---
Bugzilla, I did not ask you to clear those flags.
blocking-b2g: --- → 1.5?
status-firefox27: --- → verified
tracking-firefox27: --- → ?
Target Milestone: --- → mozilla27
Could the appropriate people restore the tracking-firefox27 and blocking-b2g flags to the values they had prior to comment 139?

(While I evidently have the privilege to accidentally clear the tracking-firefox27 and blocking-b2g flags, I don't seem to have the privilege to restore them to their prior values.)
blocking-b2g: 2.0? → ---
I guess this issue can be marked as WONTFIX JSD is removed now[1] and it was reported for Firebug, which is now using JSD2, anyway.

Sebastian

[1] Bug 800200
Yes, or INVALID, rather, as there isn't anything to fix, anymore.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: