Thanks again for the detailed description. Is it possible that you break this down to a simple test case, we can reproduce the slowdown?
Also, could you find out something about the breakpoints issue? Did it go away on the Firebug-only profile? Sebastian On Tuesday, July 15, 2014 12:24:58 PM UTC+2, stephen taylor wrote: > > > <https://lh5.googleusercontent.com/-v9V_MJJZ13w/U8UBI61MB-I/AAAAAAAAAKg/dU9Ntuyf_zM/s1600/2+-+HMTL+Panel+after+appx+1+Minute.jpg> > > > <https://lh4.googleusercontent.com/-G3sNvj989Qo/U8UBWdaBwAI/AAAAAAAAAKo/BoOfRF3zj38/s1600/3+-+HMTL+Panel+*NORMAL*+operation.jpg> > > > <https://lh5.googleusercontent.com/-pzr8FkSspIg/U8UBGdCOCxI/AAAAAAAAAKY/qcGsOkTUkiA/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 3 screen shots: > > 1) on initial page load > 2) after 1 minute - this happens at the end of page load > 3) normal operation > > thanks for the mind share on this > > S > On Sunday, July 13, 2014 6:28:30 AM UTC-4, 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/fddbd27a-e894-409f-9c9d-55f42475ecdb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
