FirePHP 0.3 Released

[Christoph Dorn]

For changes see:

- http://www.firephp.org/HQ/FinalRelease.htm
- http://www.firephp.org/Wiki/Development/Release03

I have yet to update the documentation to include the new FirePHPCore
features. That will happen this week. Mozilla Add-ons will likely not
approve the extension for another few days/week.

I'll be publishing a blog post about my plans for FirePHP 1.0 this
week.

Christoph

[cFreed]

Seems that Firebug recent versions lead to already known (and
prveviously solved) problem (issues 94 and 104).
I changed FirePHP to 0.3rc1, in order to take a look at it: then my
first simple log did'nt display in Console tab!
Back to 0.2.3... the same!

So I tested with different Firebug versions, and stated that, with
both FirePHP 0.2.3 and 0.3rc1, logging display works with FireBug up
to and including 1.4.a12, and fails with next versions (in all these
cases, HTTP response headers are the same, and visibly correct).

On May 12, 8:30 am, Christoph Dorn <christ...@christophdorn.com>
wrote:
> For changes see:
>
>   -http://www.firephp.org/HQ/FinalRelease.htm
>   -http://www.firephp.org/Wiki/Development/Release03

[cFreed]

I must correct an error in my previous message:
involved issues I refered to are 94 and *103*.
Sorry.

[cFreed]

I detected a strange (for me) behaviour of $firePHP->table(), and two
minor bugs with the variable viewer.

1. $firePHP->table()
When a null value happens in a cell, it appears as a blue "NULL"
string, with cursor as pointer, and where hover causes the viewer to
appear.
Of course, it displays simply "No Data Available": if it is a designed
feature, I don't understand how it may be useful (BTW, I didn't notice
wether it already happened with 0.2.3).

2. Viewer dimensions
When the viewer is displayed *in the above case*, it appears with two
(useless) scroll bars, regardless the choosen size (50%,70%,90%).
This happens only when displaying the null value from a cell: with a
real variable, all looks fine.

3. Viewer persistence
In any case, when the following happens:
. click to make viewer permanently displayed
. switch to another Firefox tab
. go back to to the tab where the viewer was displayed
then the viewer is no longer displayed (ok, was already the same with
0.2.3), but cannot be invoked anew: clicking any of the logged lines
(or any cell in the case of table as said above) does nothing, though
cursor still appears as pointer.
I suspect something like FirePHP extension remembers that the viewer
was currently (logically) displayed, but ignoring it has physically
disappeared.

[cFreed]

Some supplemental observations...

Regarding point 2 of my previous message: in fact, viewer may include
useless scroll bar(s) in other cases than the one I already reported.

When console displays the uncollapsed contents of an error report,
click on a *string* argument in a code line: you may briefly see the
viewer display a scroll bar before finally displaying without it.
Clicking on an *array* argument doesn't.

Unfortunately I cannot actually reproduce what I got once in addition:
having clicked as explained above, I got the viewer fixed with a
vertical scroll bar, and *no* bottom limit of its window!

[Christoph Dorn]

Hmm. It is working for me. I just tried the following without
problems:

- Firefox 3.0.10
- http://getfirebug.com/releases/firebug/1.4/firebug-1.4.0a27.xpi
- http://www.firephp.org/HQ/FinalRelease.htm (0.3 final extension and
server lib)

Test Page: http://www.firephp.org/

Are you getting headers sent to the client?

Christoph

[Christoph Dorn]

> 1. $firePHP->table()
> When a null value happens in a cell, it appears as a blue "NULL"
> string, with cursor as pointer, and where hover causes the viewer to
> appear.
> Of course, it displays simply "No Data Available": if it is a designed
> feature, I don't understand how it may be useful (BTW, I didn't notice
> wether it already happened with 0.2.3).

It also happens with 0.2.3. It is a design limitation of the variable
viewer code that I will not be fixing until FirePHP 1.0.

> 2. Viewer dimensions
> When the viewer is displayed *in the above case*, it appears with two
> (useless) scroll bars, regardless the choosen size (50%,70%,90%).
> This happens only when displaying the null value from a cell: with a
> real variable, all looks fine.

This is also a design limitation of the current variable viewer that
will be resolved in FirePHP 1.0. I had to opt for a pretty ugly
implementation for the variable viewer when I coded it originally to
make it compatible with Firefox 2 and early versions of Firefox 3.
FirePHP 1.0 will be Firefox 3+ only and use a completely re-written
codebase that takes advantage of FF3 features that were a bit buggy
until recently.

> 3. Viewer persistence
> In any case, when the following happens:
> . click to make viewer permanently displayed
> . switch to another Firefox tab
> . go back to to the tab where the viewer was displayed
> then the viewer is no longer displayed (ok, was already the same with
> 0.2.3), but cannot be invoked anew: clicking any of the logged lines
> (or any cell in the case of table as said above) does nothing, though
> cursor still appears as pointer.
> I suspect something like FirePHP extension remembers that the viewer
> was currently (logically) displayed, but ignoring it has physically
> disappeared.

Right. I usually just refresh the page as a work around. This will
also be fixed with the new viewer implementation in FP 1.0.

Christoph

[Christoph Dorn]

> Regarding point 2 of my previous message: in fact, viewer may include
> useless scroll bar(s) in other cases than the one I already reported.
>
> When console displays the uncollapsed contents of an error report,
> click on a *string* argument in a code line: you may briefly see the
> viewer display a scroll bar before finally displaying without it.
> Clicking on an *array* argument doesn't.
>
> Unfortunately I cannot actually reproduce what I got once in addition:
> having clicked as explained above, I got the viewer fixed with a
> vertical scroll bar, and *no* bottom limit of its window!

I have observed a lot of strange behaviour with the variable viewer
myself. It was a pain to implement and I am surprised it is still
working acceptably. The viewer in FP 1.0 will be *MUCH* improved.

Thanks for all your feedback.

Christoph

[Christoph Dorn]

The Use [1] page has been updated to include the new features and
information about PHP4 support.

Christoph

[1] - http://www.firephp.org/HQ/Use.htm

[Christoph Dorn]

So far we have received 1705 downloads of the extension and 448
downloads of the FirePHPCore library. This is from users who update
FirePHP from www.firephp.org.

Christoph

[TiTerm]

Not so bad in just few days;

Carry on :)

[cFreed]

1. REGARDING FIREBUG VERSIONS
Not so easy to understand what happens successively.

I absolutely confirm to have *precisely* tested with different
versions of Firebug, as I reported, up to 1.4.0a26
(which was my current version at the moment).
For me too, Firefox is 3.0.10, and sure I had installed the 0.3 server
lib *and extension* :-).
And yes, for all these cases, I got the right headers.

Then today I upgraded to 1.4.0a27 and:
. first I got a never seen yet failure: Console tab displayed only
"Error executing default FirePHP processor! TypeError: context is
null message=context is null"
. but later, *having had to reboot*, I now observed that all worked
fine
. and actually it works even with older Firebug versions

I'm really puzzled.
I use to observe Firebug weaknesses which makes it silently fail for
some functions while it seems globally working
yet. But in these cases, closing Firefox and relaunching it is
sufficient to get a new clean situation (and then it
often seems that Firefox itself is involved, since it doesn't stop
once closed, and must be killed through the task
handler).
And when I tested successive versions, obviously Firefox was stopped
and launched each time I changed, so it cannot be the same.
In the other hand, I don't at all figure out how rebooting may have
cleaned something else...

In any case, for a couple of weeks, I experienced many erratic
problems with the so numerous recent versions of
Firebug :
. sometimes an empty HTML tab just after loading (re-displays when
switching to another tab then switching back to
HTML tab)
. sometimes loosing the inspector highlighting when hovering HTML
code (seems to happen after certain HTML code
changes)
. sometimes Net tab does not trace loaded pages (then quite obviously
FirePHP logging doesn't display)
. sometimes opening Firebug on a given Firefox tab I get the current
state of another one
. and recently a new one: separate Firebug window remains entirely
empty after switching elsewhere and coming
back!
Haven't you got some of these problems?

Seems that as of 1.4, Firebug has many bugs: today there are more than
150 new issues in bug tracker since the one
I opened March 28 (this one has been fixed), and none of those new
ones seem to point what I reported just above!
I don't want to be critical, since Firefox is a great tool: just say
that they have a lot of problems for now.
So for me, too hard to follow this... wait and see...

Anyway, now for me FirePHP works with any Firebug version.

2. FireHP MINOR BUG FOUND
Normally, hovering a logging line displays the source file and line
number where it was invoked.
But with 0.3, what is displayed is always ".../FirePHP.class.php :
510".
I guess this is easy to correct, since it is probably a simple level
error when using the trace stack.


On May 13, 3:11 am, Christoph Dorn <christoph...@christophdorn.com>
wrote:

> Hmm. It is working for me. I just tried the following without
> problems:
>
> - Firefox 3.0.10
> -http://getfirebug.com/releases/firebug/1.4/firebug-1.4.0a27.xpi

> -http://www.firephp.org/HQ/FinalRelease.htm(0.3 final extension and

[Christoph Dorn]

> Seems that as of 1.4, Firebug has many bugs: today there are more than
> 150 new issues in bug tracker since the one
> I opened March 28 (this one has been fixed), and none of those new
> ones seem to point what I reported just above!
> I don't want to be critical, since Firefox is a great tool: just say
> that they have a lot of problems for now.
> So for me, too hard to follow this... wait and see...
> Anyway, now for me FirePHP works with any Firebug version.
>

Firefox/Firebug definitely have their glitches at times. I have been
able to avoid most upgrading/downgrading issues by using separate
profiles for testing different versions of FirePHP/Firebug and Firefox.

FirePHP 1.0 will not require Firebug by default, but will use it if
available. This way FirePHP is still usable even if Firebug has some
glitches in it.

> 2. FireHP MINOR BUG FOUND
> Normally, hovering a logging line displays the source file and line
> number where it was invoked.
> But with 0.3, what is displayed is always ".../FirePHP.class.php :
> 510".
> I guess this is easy to correct, since it is probably a simple level
> error when using the trace stack.
>

This is working for me. Are you using a sub-classed or modified version
of the core library?
Can you send me a test case.

Christoph

[Christoph Dorn]

We are at 3,392 downloads for the extension and 1260 for the
FirePHPCore library.

It has been leveling off over the last few days. Now we need to wait
for mozilla to review the new release.

Christoph


On May 13, 9:18 pm, Christoph Dorn <christoph...@christophdorn.com>
wrote:

[cFreed]

Sorry for that long silence.
I was totally stuck for a time with a hardware problem which then
turned to software problem (I finally had to reinstall all of my
software tools).

And for what I reported previously, I definitely don't understand
anything!
In my last message, I said I had FirePHP log working, but with an
erroneous source file/line (FirePHP.class.php: 510).
Then it suddenly became false, as again I didn't get log any longer,
for a time.
But recently, when receiving Firebug 1.4.a029, I retrieved the FirePHP
logs, with a correct source file/line!
And finally, just now, I get logs but with the false source file/line.
Sigh...

For a test case, you may go at http://ks353756.kimsufi.com/quetelet/
It is a totally open tests site, and you may use the vertical tool bar
on the left to:
. click the "*" button (debug console), then check "Enable test mode"
and click to Validate options
. click the "?" button (test tool), then write and execute PHP code,
like: fp('Some text','Label'); and see what happens
fp() is my own implementation of FirePHP, which uses an already
created FirePHP object, but you may also use the normal way
($firephp=FirePHP::getInstance(true); etc...)

If it doesn't change meantime, you should currently get the expected
log, with the false source file/line.
My unique guess trying to explain how it may be alternatively working
or not, is that the context (a real application) is complex enough to
sometimes fall in somethig wrong: hope you will get it.

Yes, I'm using a modified version of the core library (I replaced the
encodeTable() function as explained earlier), but it is the same when
it works and when it doesn't!
In any case, to ensure it is not involved, you may look at this
version:
. click the "." button (file contents inspector) of the tool bar
. in the /home/ovh/www/__webtools part, click "libs", then
"FirePHPCore-0.3rc1" and "FirePHP.class.php": you will get the actual
contents; the encodeTable() function (line 1005) is the only change I
made

On May 19, 5:31 pm, Christoph Dorn <christoph...@christophdorn.com>
wrote:

[TiTerm]

With firebug 1.4x0.a30 and firefox 3.5 tuesday nightly build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090527 Shiretoko/3.5pre ID:20090527044141)

When i enable test mode, then validate, i have a message log
Template from HtmlUserConnection[huc]->html_user_connect(): array ...

from FirePHP.class Line 510

When i execute fp('Some text','Label');
i have the correct log from same line 510

In issue 62, long time ago, i had upload in comment #4 a way to fix
the false line issue.
I know christoph have fix it for 1.0 but i don't know how.

Like you, i have a custom FirePHP class and i don't use it directly, it's wrapped in my own debug function,
that's why i had fix line number/file  issue.

[cFreed]

>>Template from HtmlUserConnection[huc]->html_user_connect(): array ...

Normal: this is a permanently embedded log, active only when in test
mode.

>>from FirePHP.class Line 510
AND
>>In issue 62, long time ago...
Yes! I was stupid: as soon as explained, it becomes obvious that
FirePHP cannot know how deep is the call stack.

But what keeps me puzzled is: why may it sometimes work properly
without changing the calling way?
May be I will discover that I don't really call it the same way. Seems
not realistic, but...

Just now, I don't have the needed time to widely read issue 62
comments, but I will do it soon.
Thanks to have pointed me to this.

> > For a test case, you may go athttp://ks353756.kimsufi.com/quetelet/