> *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
>
Does it work for you using Firebug 2.0.2? At least so far I couldn't
reproduce this.
My steps:
1. Opened Firebug on the attached test case
2. Enabled and switched to the Script panel
3. Reloaded the page
=> Script execution stopped at line 9 (at the debugger keyword as
expected)
4. Continued the script execution
5. Reloaded the page again
=> Script execution stopped at line 9 again (as expected)
6. Clicked the Disable button within the breakpoint notification
7. Removed the debugger keyword from the script
8. Reloaded the page
=> Disabled breakpoint was still there but didn't get hit. (as expected)
If you have reproducible steps, please post them here.
> *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
>
Well, it's a lot of information and hard to reproduce that on my side. So
to reproduce this it would be great if you could either create a simple
test page including the programmatic steps above or provide us access to
your system. For the latter you can email me the information to
sebastianzartner at gmail dot com and/or to Honza, our team leader, at
odvarko at gmail dot com.
One more question: Does this slowdown also occur using the built-in
DevTools?
Sebastian
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/6f9d6ac2-818d-42fd-a2ae-0f8c355e1d7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Title: Title
