<https://lh6.googleusercontent.com/-VVcOELMDpjM/U8T_9F25VBI/AAAAAAAAAKI/bMKBfljlP7o/s1600/2+-+HMTL+Panel+after+appx+1+Minute.jpg>
<https://lh6.googleusercontent.com/-f6ktMrfE-Rg/U8T_6v73jKI/AAAAAAAAAKA/MWGZQv37FvI/s1600/1+-+HTML+Panel+after+full+page+load.jpg> Thanks for the attention - huge fan of FB and we rely heavily on it. As it turns out, firePHP does not seem to contribute to the latency. I have multiple profiles with various configurations - including one with firebug only and one with one with FB and Web Developer tools extension. After an initial evaluation where the problem *seemed* to go away, it (oddly) returned. I can provide more detail but it is true that these scripts (in a Single Page App) contain various POST and GET requests, a complex DOM where multiple UI widgets being instantiated or destroyed and manipulated (with JQ) as needed. Until FB 2.01, this was not a problem. Here's the thing: the long latency in updating the HTML panel (and the console) is mainly present on a full page refresh (that is, not an ajax-based navigation interaction). The latency can be up to 1 min. If, during this period, interactions with page elements take place, when the HTML panel (and console) catch up, it looks like all the previous interactions are reflected in the HTML Panel (and withdrawn) - - it looks like these are cached waiting for some process to complete? Here is a description of a typical scenario: 1) refresh from browser 2) page loads - initial view is reflected in the HTML panel but none of the JS-based UI manipulations are revealed in FB - though they are present in the Browser example: main page elements are loaded but a view of a particular block within the current page is fetched (via GET) and injected into the DOM. Right-click selection of these injected elements (via "view element") (for example) shifts focus to the FB HTML panel but the injected elements are not yet shown in that Panel - yet is visible to the user and the events that are attached to that view are active. Note also that console.log notes that occur in the course of executing this view are not present. 3) after the "wait" time, the DOM panel lights up, showing the injected elements with all the JS-driven events and the console reads out all the logs and timers we have set. After the initial wait time, all seems to operate as normal. As a specific instance, on one "page" we have a number of kendo widgets - in this case dropdowns. The drop down elements are functionally active during the wait time (as are the events attached to them) but (as kendo users know), the drop down containers themselves are stored at the bottom of the body. In *normal operation*, these are shown in the HTML Panel immediately upon binding. In the "wait state", they appear up to 1 minute later. If, during that "wait state", another "page" is selected, the JS destroys the kendo widgets - while they vanish from the Browser, in the wait state, nothing happens in the HTML panel. That is, if you select a new "page" (and thus destroy these widgets) during the wait time, when the Panel does "catch" up, the first set of widgets (now destroyed and removed) are shown briefly but then deleted - and if the selected new "page" also has widgets, these replace the destroyed ones. The console reads out all the logs up to that point. I am trying to be specific as possible - - here are 2 screen shots: 1) on initial page load 2) after 1 minute - this happens at the end of page load thanks for the mind share on this S On Monday, July 14, 2014 11:50:44 AM UTC-4, Christoph Dorn wrote: > > > > 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 > <[email protected] <javascript:>> 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 > >>>> > >>> > > -- 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/0b66fdc5-33a6-4230-80ab-6f6125a67b09%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
