problems with v2.01

[stephen taylor]

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

[Sebastian Zartner]

I can't reproduce the slowness you describe. What exactly do you mean with "DOM view"? The HTML panel, the DOM panel, or what?
Can you reproduce that on a fresh Firefox profile with just Firebug installed?

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 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.

Sebastian

[stephen taylor]

@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

[Sebastian Zartner]

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

[Carlos Santana]

I am using the same configuration, but do not experience these kind of speed problems (Win 7x4).

One problem I do have (sometimes) and which has been reported already, is, "phantom breakpoints":

breakpoints are still in effect after they have been removed.

[stephen taylor]

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

[Sebastian Zartner]

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

[stephen taylor]

@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

[Sebastian Zartner]

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.
 

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

[Mahks]

I am seeing a similar delay in messages being placed in the console.
@Stephan, How did you fix the problem?

I also have the problem of not being able to remove breakpoints without a reload.
My breakpoints are in iframes, I assumed the problem was part  with the iframe reload issue since the JSD2 implementation.

FF 32.0.3
FB 2.0.4 (only addon)
Fresh profile