@Sebastian Thanks for the reply and sorry for the lack of clarity. I do indeed mean the HTML panel when I refer to DOM view. Note that the console seemed to have followed the same timeline as the HTML panel.
Since we use FF only for dev work, I have created a new "firebug only" profile. This eliminated my issues in very cursory tests. I then added the few must-have extensions I require (web developer, measureIt and colorZilla) and it seemed to be OK. I then added another must-have - - firePHP. In the default profile removing this seemed to help but in the new "firebug only" profile things seem fine. I will continue to test but clearly there is some issue with the default profile. I will continue to monitor. Thanks so much! S Hmmm. I will have to look into why this might be. I am using firePHP 0.74 On Sunday, July 13, 2014 12:08:52 PM UTC-4, Sebastian Zartner wrote: > > I can't reproduce the slowness you describe. What exactly do you mean with > "DOM view"? The *HTML* panel > <https://getfirebug.com/wiki/index.php/HTML_Panel>, the *DOM* panel > <https://getfirebug.com/wiki/index.php/DOM_Panel>, or what? > Can you reproduce that on a fresh Firefox profile with just Firebug > installed > <https://getfirebug.com/wiki/index.php/Install_Firebug_into_a_clean_profile> > ? > > Could you please describe what you mean by "breakpoints do not seem to > removable"? Is the breakpoint still shown within the breakpoint column and > *Breakpoints* side panel > <https://getfirebug.com/wiki/index.php/Breakpoints_Side_Panel> when you > try to remove them? Or are they gone but the script execution still stops > at the position where you removed the breakpoints? > The latter problem is treated in issue 7301 > <https://code.google.com/p/fbug/issues/detail?id=7301>. > > Sebastian > > On Sunday, July 13, 2014 12:28:30 PM UTC+2, stephen taylor wrote: >> >> >> Since FF 30 and FB v2.01, this invaluable tool had become (for us) >> practically unusable due to: >> >> 1) extremely slow update of the DOM view - sometimes several minutes >> after injecting or removing elements. >> 2) console readouts just as slow - so that (for example) runtime JS >> errors are not evident for quite a long time >> 3) breakpoints do not seem to removable except by restarting FF. >> >> Regarding points 1) and 2) >> >> This is not always repeatable - that is, it seems the "wait" time >> (latency of the responsiveness) is variable - and sometimes is not >> perceptible at all. >> >> We use FB throughout our dev group and have only a few plugins enabled - >> mainly things like Web Developer. >> >> We have tried turning off the scripts and net tabs (and obviously >> foregoing breakpoints) but no love. >> >> Note that the current app under development is a single app that relies >> heavily on jQuery with multiple ajax calls fired by various events, >> including various navigation and user options. >> >> I am not sure what is most helpful here but here is an example: >> >> 1) Load page - can take up to 1 minute to update FB DOM view and console >> readout >> 2) select a "page" thru primary navigation >> - this triggers a ajax call that results in injection of HTML into the >> "re-writeable" section of the DOM >> - FF renders as expected but the FB DOM panel does not update for up >> to a minute >> - all console messages delayed until that time >> >> Has anyone seen this? suggestions? >> >> S >> > -- You received this message because you are subscribed to the Google Groups "Firebug" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/firebug. To view this discussion on the web visit https://groups.google.com/d/msgid/firebug/cb182dd0-0757-4547-92c8-cbe4c03a6dac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
