Logging doesn't work in IE8
Closed this issue · 14 comments
IE doesn't produce any log into developer tools, Chrome for example, works just fine. Also, every call to p() (when using stream mode) results "Object doesn't support this property or method" exception. When "[Stream] message received" log call is removed, exceptions are no longer produced.
This can also be tested on http://www.nginxpushstream.com/chat.html
Thanks for the report.
Which developer tools are you using?
On Tue, Apr 3, 2012 at 1:54 PM, tarko <
reply@reply.github.com
wrote:
IE doesn't produce any log into developer tools, Chrome for example, works
just fine. Also, every call to p() (when using stream mode) results "Object
doesn't support this property or method" exception. When "[Stream] message
received" log call is removed, exceptions are no longer produced.This can also be tested on http://www.nginxpushstream.com/chat.html
Reply to this email directly or view it on GitHub:
#22
IE8 builtin
I tried to reproduce the problem but was a little unstable (I'm using a virtual machine).
Can you please apply this patch to your file and check if it solve the problem on IE8?
Nope, doesn't fix it.
The issue is even more strange. It doesn't happen when first visiting the page. If you reload the page (or navigate away), it looks like old iframe is kept alive (all DOM is supposed to be destroyed) and you end up with two active iframes. Now the "old" iframe starts logging this error, probably because everything else surrounding it is already gone. If you keep reloading the page, all the iframes are kept until you hit the IE connection limit for single host and new page cannot be reloaded any more.
And yes, the iframes really are active. All TCP sessions are there and they are all receiving periodic pings. If you push data, you can see from developer tools that all iframes receive it.
I'm not a web developer but I'm pretty sure it's not supposed to happen. Sounds like a IE bug to me unless there is a workaround by somehow destroying the iframe explicitly? My only windows development machine is also VM with XP inside but I'll try to find IE9 and check with that. God I hate IE :)
This will help me a lot to check the problem.
Thanks for the report, I will check the lifecycle of iframe.
I hate IE too :)
Regards
On Wed, Apr 4, 2012 at 11:53 AM, tarko <
reply@reply.github.com
wrote:
Nope, doesn't fix it.
The issue is even more strange. It doesn't happen when first visiting the
page. If you reload the page (or navigate away), it looks like old iframe
is kept alive (all DOM is supposed to be destroyed) and you end up with two
active iframes. Now the "old" iframe starts logging this error, probably
because everything else surrounding it is already gone. If you keep
reloading the page, all the iframes are kept until you hit the IE
connection limit for single host and new page cannot be reloaded any more.And yes, the iframes really are active. All TCP sessions are there and
they are all receiving periodic pings. If you push data, you can see from
developer tools that all iframes receive it.I'm not a web developer but I'm pretty sure it's not supposed to happen.
Sounds like a IE bug to me unless there is a workaround by somehow
destroying the iframe explicitly? My only windows development machine is
also VM with XP inside but I'll try to find IE9 and check with that. God I
hate IE :)
Reply to this email directly or view it on GitHub:
Hi, I applied a fix to this problem.
Test again with the latest pushstream.js version to see if it is ok to you.
Regards
Thanks, this seems to fix it, no more errors appear and iframes doesn't get stuck according to dev tools.
Broken IE8+ logging seems to be different issue, IE doesn't support console.log.apply. See http://whattheheadsaid.com/2011/04/internet-explorer-9s-problematic-console-object for possible workaround.
Good news.
For IE8+ you can use the feature of adding a div with the id Log4jsLogOutput (or any other and pass it in PushStream.LOG_OUTPUT_ELEMENT_ID constant) and pushtream.js will log to this div.
I will try to use the IE8+ console.log, but it isn't the priority right now, sorry.
Sure I can. I've actually patched my local copy to use console.log instead, output isn't that nice (array) but it gets the job done.
Hi,
could you try the code on branch longpolling_with_array_support?
It is with a code to log in IE8 and IE9 console.log, and with support for
receive old messages in a single package.
On Mon, Apr 9, 2012 at 4:10 AM, tarko <
reply@reply.github.com
wrote:
Sure I can. I've actually patched my local copy to use console.log
instead, output isn't that nice (array) but it gets the job done.
Reply to this email directly or view it on GitHub:
It's better, "LOG: [Stream] message received,[object Object]" messages now appear in log console but all previous log messages generated on startup are still lost. They are logged into HTML element though.
PS! The new message parsing method breaks messages where message text is also a JSON string. Previously it was parsed out using regexp and you could run JSON.decode on it yourself. The full message obviously isn't valid JSON. If it'll stay that way it's probably worth mentioning it in the documentation.
Hi,
The messages of startup appears if the console is open when the page load,
do a refresh to test, please.
If you use the pushstream.js to publish the message the escape is done
correctly.
Yes, I will adjust the documentation yet. Because of that I put the code on
a branch, it is under test, and docs too. :D
Thanks for testing and for the feedback.
On Tue, Apr 17, 2012 at 8:58 AM, tarko <
reply@reply.github.com
wrote:
It's better, "LOG: [Stream] message received,[object Object]" messages now
appear in log console but all previous log messages generated on startup
are still lost. They are logged into HTML element though.PS! The new message parsing method breaks messages where message text is
also a JSON string. Previously it was parsed out using regexp and you could
run JSON.decode on it yourself. The full message obviously isn't valid
JSON. If it'll stay that way it's probably worth mentioning it in the
documentation.
Reply to this email directly or view it on GitHub:
hey,
The messages of startup appears if the console is open when the page load,
do a refresh to test, please.
Thats exactly what I did and it didn't make difference.
tarko
humm, here the messages appear (print screen in attach).
which message you are not seeing?
On Tue, Apr 17, 2012 at 11:28 AM, tarko <
reply@reply.github.com
wrote:
hey,
The messages of startup appears if the console is open when the page
load,
do a refresh to test, please.Thats exactly what I did and it didn't make difference.
tarko
Reply to this email directly or view it on GitHub: