The only issue reported for Firebug 2.0 so far is:
*
https://github.com/firephp/firephp-extension/issues/21
Christoph
On July 14, 2014 08:35:46 AM EDT, Sebastian Zartner
<
sebastia...@gmail.com> wrote:
> Thanks already for the detailed feedback! Please let us know if you
> find out more.
> I CC'ed Christoph Dorn, which is the author of FirePHP. So maybe he
> can give some more advice.
>
> Sebastian
>
> On Monday, July 14, 2014 1:12:12 PM UTC+2, stephen taylor wrote:
>>
>> @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
>>>>
>>>