@Sebastian
Thanks again for your attention.
*Also, could you find out something about the breakpoints issue? Did it go
away on the Firebug-only profile?*
Inserting a breakpoint (via "debugger") in one of the init scripts, the
following occurred:
1) breakpoint triggered
2) "continue" operated as expected;
3) on continued triggers: "disable" operated as expected;
However:
- removal of the debugger command *did not* remove the breakpoint in FB on
reload of the script (browser refresh with caching disabled)
- that is, the red dot in the scripts persisted on the line where the
debugger had been previously present and the breakpoint continued to be
triggered
- required restart of the browser to remove the breakpoint - both red dot
and the breakpoint itself
That is puzzling
*Is it possible that you break this down to a simple test case, we can
reproduce the slowdown?*
Well, in general, while the structure of the app is rather complex, the
pattern is fairly repeatable:
1) initial page load is typical HTML5 where the assets are delivered
(including all scripts, CSS and images) and the HTML (empty) targets are
initialized - where the targets are id-based elements that received
injected HTML. This is a layout view rendered through the Yii framework.
2) using jQ .ready(), we trigger an initial POST to retrieve "page info"
and HTML, where the HTML is subsumed within a JSON object;
3) using a deferred structure, on completion of the initial POST, if there
are widgets (sometimes kendo or other UI structures) on the page, we
trigger a POST to get data and HTML specific to the specific "sub-page" and
other fragments
4) on completion of this POST, again under a deferred promise sequence, we
initialize the widgets and release the UI.
We know this process completes as designed for a number of reasons - - that
is, we use a clear mask (with a very high z-index) to disable UI
interaction while the promise sequence executes; this is released after the
final promise is resolved. In addition, in development we frame each
promise with a console.time([*name*]) - console.timeEnd([*name*]) pair to
verify the execution is sequenced correctly.
Thus, in summary:
Initial page load
execute init under deferred promise - - on resolve()
Ajax POST
execute stuff (appx 700 mS)
POST (chained to previous ajax POST using .done()
execute stuff (appx 700 mS) under deferred promise
on resolve()
Release UI
I suppose we could give access to a demo but this is very sensitive client
site and we could not give access through a forum.
One thought occurs to me: we use a console control function initialized in
an init script but outside of the jQ .ready(). I have used this for years
and have never had an issue. This code block is shown below:
var consoleHolder = console;
function doConsoleLog(doConsole){
if (!doConsole) {
consoleHolder = console;
console = {};
console.log = function(){};
console.time = function(){};
console.timeEnd = function(){};
console.dir = function(){};
console.clear = function(){};
}
else {
console = consoleHolder;
}
}
//set argument FALSE to disable console
doConsoleLog(false);
The consoleHolder variable is the only global we use - all other variables
are scoped within functions. I tried eliminating this function but no
effect that I could see - I also tried dialing all the panels except for
HTML - again no effect.
Hope this is not too much detail
S
On Thursday, July 17, 2014 5:22:06 AM UTC-4, Sebastian Zartner wrote:
>
> 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/678e7daf-988d-46bf-acd8-a888b1b546f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
