| Package home | Report new bug | New search | Development Roadmap | Status: Open | Feedback | All | Closed Since Version 1.14.4 |
| Request #12607 | avoid errors in IE if logging to firebug console | ||
|---|---|---|---|
| Submitted: | 2007-12-04 11:08 UTC | ||
| From: | matokl | Assigned: | jon |
| Status: | Closed | Package: | Log (version 1.9.11) |
| PHP Version: | Irrelevant | OS: | any |
| Roadmaps: | 1.9.12 | ||
[2007-12-04 11:08 UTC] matokl
(Martin Klobusnik)
Description:
------------
was wondering if it would be possible to add a tiny bit of check to avoid having errors while logging to the firebug console in IE.
so on line 201 (firebug.php) instead of having:
printf('console.%s("%s");',
it would say:
printf('if(window.console) console.%s("%s");',
Comments
[2007-12-04 16:35 UTC] chagenbu
(Chuck Hagenbuch)
I guess it's not a big deal, but why would you enable the firebug logger when you're not using firebug? This should really only be for development situations, not production, not a big deal to do a browser sniff in your code before enabling the logger, also...
[2007-12-10 00:03 UTC] jon
(Jon Parise)
It looks like all of the lines which write to the console object are already wrapped in this test:
if (('console' in window) || ('firebug' in console)) {
// use the console object
}
Is this not preventing the errors in IE?
[2007-12-10 09:39 UTC] matokl
(Martin Klobusnik)
jon: console object you are refering is I believe not the firebug.console object. There is definitely an error in IE if firebug is used as a handler.
chagenbu: of course I use it only in developement stage, however PMs are using IE to look at the staging version and that's the place when they see errors. You are right, It's not a big deal to do the browser check beforehand but it would be nicer not to worry about it every time.
[2007-12-10 17:45 UTC] jon
(Jon Parise)
Ok, I'll try and take a look at this in the next couple of days. It shouldn't be hard to fix.
Do you know if there's anything different about IE6 versus IE7 here?
[2007-12-11 16:51 UTC] jon
(Jon Parise)
This bug has been fixed in CVS.
If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET).
If this was a problem with the pear.php.net website, the change should be live shortly.
Otherwise, the fix will appear in the package's next release.
Thank you for the report and for helping us make PEAR better.
It looks like this was fixed back in June, but it hasn't made it into a public release yet. I'm very sorry about that; I didn't realize there were unreleased fixes still setting in the repository. (That's why some of us weren't seeing the problem.)
I'll release package version 1.9.12 soon with the fix for this.