<https://lh6.googleusercontent.com/-oA3A9LW8LLM/U8UA4CDIjuI/AAAAAAAAAKQ/ElhiYqApZuM/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 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/18a72a95-ecf5-428c-ab24-a78f5d23c14a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
