What versions and operating system are you using?
OS:Windows 7 Ultimate 64bit Firefox: 9.0.1 Firebug: 1.9 FirePHP Server Library: Zend Server Library 1.6.2 / Zend Framework 1.11.11 FirePHP Extension: 0.7.0RC2
What is the problem? FirePHP will only receive Log Responses for however long the site is not refreshed. Reloading will reset FirePHP to not receive log Responses from the server. Disabling / Enabling FirePHP through its Icon will enable FirePHP to receive Log Responses (e.g. AJAX Responses) until the Page is refreshed / reloaded again.
What steps will reproduce the problem? 1. Call Page with Zend_Log_Writer_Firebug(); debug output 2. Disable / Enable FirePHP 3. Call AJAX Request on same Page without reloading / refreshing and receive Log Responses
What is the expected output? What do you see instead? Normal Log Responses as before under FF 8+ and Firebug 1.8 from the Beginning. Now you have to Disable / Enable after every page refresh and normal / non AJAX Log-Output will not be displayed even after this workaround.
Please provide any additional information below. We suspect it might have something to do with FireBug / FirePHP not sending the correct Request Headers / setting the correct UA Addition on Pageload. It will only send those when the extension is disabled / enabled.
Comment #1
Posted on Jan 11, 2012 by Happy Camel(No comment was entered for this change.)
Comment #2
Posted on Jan 11, 2012 by Happy CamelComment #3
Posted on Jan 12, 2012 by Happy CamelAs a workaround you can use DeveloperCompanion on the client:
http://developercompanion.com/
No license or changes on server required.
Comment #4
Posted on Jan 13, 2012 by Massive BirdSimple dirty hack for developer only machines, until this is fixed: public function detectClientExtension() { // just ignore if headers have been sent or not, we KNOW FirePHP is installed... return true; // original function code here: ... ... }
Comment #5
Posted on Jan 13, 2012 by Happy CamelI have been trying to reproduce the problem but cannot. Can someone put together a reliable test case or video showing the problem?
What could also help is the output of the Firebug tracing console [1] with the "FirePHP" option enabled.
If you are adventurous you can install [2] the extension from source [2] and add more logging calls to figure out what is going on.
[1] - http://getfirebug.com/wiki/index.php/FBTrace [2] - https://developer.mozilla.org/en/Setting_up_extension_development_environment#Firefox_extension_proxy_file [3] - https://github.com/firephp/firephp-extension
Comment #6
Posted on Jan 13, 2012 by Quick HorseAbsolutely - will try to update you with new Information on Monday.
Comment #7
Posted on Jan 16, 2012 by Quick HorseUpdate on the issue:
I installed FB Trace and am attaching a Trace of the problematic behaviour:
Lines 1 - 55:
I refresh the page I expect to get console logs with enabled FirePHP Plugin. I noticed line 24 where it says FirePHP is disabled. I double and triple checked that it was enabled before refreshing.
Line 56 - 61:
I request (AJAX) Actions on the same page which should respond with logging replies (which do not get rendered)
Line 62 - 66: I explicitely disable and enable FirePHP without reloading the page. I noticed that there are 2 enable calls (line 65-66)
Line 67-94: I call Zend Actions through AJAX requests again and this time I get the responses in Firebug log tab / network tab I expect.
Hope it helps, Richard
- firebug-tracing-logs.ftl 145.03KB
Comment #8
Posted on Jan 19, 2012 by Happy Camelrichard.muehlehner Thanks.
I think I found the bug. Try this: https://s3.amazonaws.com/download.sourcemint.com/github.com/firephp/firephp-extension/-stream/stable/firephp-extension-0.7.0rc3.xpi
Comment #9
Posted on Jan 19, 2012 by Quick HorseComment deleted
Comment #10
Posted on Jan 19, 2012 by Quick HorseActed to quickly - after more tests we found out that the original problem has only altered. Referring to my trace above, responses which are supposed to be read at pageload (Line 1-55) are not rendered correctly. Followup logger requests / responses (ajax) will be rendered correctly now without enabling / disabling the addon.
So the problem is still there but different.
Comment #11
Posted on Jan 19, 2012 by Happy CamelCan you attach another dump of the logs please.
Comment #12
Posted on Jan 20, 2012 by Quick HorseTy again for taking time to fix this - here is the requested new log.
I also attached a screenshot from DevCompanion on the same page, showing that there is indeed a console response on Pageload which will not be displayed in FirePHP.
- screenshot_devcompanion.jpg 90.14KB
Comment #13
Posted on Jan 20, 2012 by Happy CamelThanks for the info. I should have some solid time on Monday to try and get this fixed.
Comment #14
Posted on Jan 24, 2012 by Happy CamelComment deleted
Comment #15
Posted on Jan 24, 2012 by Happy CamelPlease try new release: https://s3.amazonaws.com/download.sourcemint.com/github.com/firephp/firephp-extension/-stream/stable/firephp-extension-0.7.0rc4.xpi
Diff: https://github.com/firephp/firephp-extension/commit/4e176897ea067b328aeebc82cb33af4cf3aa91c0
Comment #16
Posted on Jan 24, 2012 by Quick HorseHi Christoph,
I'm sorry to report that rc4 didn't change the reported behaviour. Please see attached new log. I can see that there are somehow messages queued but never rendered on pageload. AJAX calls with log responses still render fine.
- ftl-240111.ftl 161.8KB
Comment #17
Posted on Jan 24, 2012 by Happy CamelRelated firebug issue: http://code.google.com/p/fbug/issues/detail?id=5179
Comment #18
Posted on Jan 24, 2012 by Happy CamelBugfix that will likely not fix things: https://s3.amazonaws.com/download.sourcemint.com/github.com/firephp/firephp-extension/-stream/stable/firephp-extension-0.7.0rc5.xpi
The original issue reported has been fixed (enable/disable with headers not sent).
Please open new issue describing remaining problem in detail. Please try with a fresh firefox profile with nothing other than firebug and firephp installed. If problem persists I will tweet the issue and ideally need a test case as I cannot reproduce the issue.
Comment #19
Posted on Jan 24, 2012 by Happy Camel(No comment was entered for this change.)
Status: Fixed
Labels:
Type-Defect
Priority-Critical
Milestone-Extension-0.7