Can you please provide some info on how to reproduce this, e.g. page/beans code?
its reproduceable on the richfaces demo page itself.
If you just switch one of the tab panels the httpwatch shows you this ERROR_INTERNET_INVALID_URL message when using internet explorer.
Sorry, I cannot do that. HttpWatchPro refuses to install without valid license file, and HttpWatch refuses to show information for localhost. Log inspection is allowed in basic version, so can you please attach log here? Please do not forget to strip all sensitive/personal information.
Thanks for your reply on my thread. You´re right, I also noticed the bad performance impact of these https://:/ calls. We use richfaces 3.2.3 SR1.
I used HTTPWatch Version 3 for my performance analysis. The download for this older Version is offered at the end of the HTTPWatch download site.
Version 3 can be installed even without a license key. The only limitation is that tracked url sequences can´t be exported.
In my analysis of this issue I discovered two things. First these Invalid URLs always follow the call for a javascipt file. A colleague of mine mentioned that he watched simiar URL calls in connection with the usge of Prototype Java Script Framework. As far as I know richfaces also uses this framework.
Second, looking for a free httpwatch alternative I found httpfox as a firefox complement. Calling the same URL sequence with httpfox I noticed that httpfox does not record these invalid url calls. In my opinion there are three reasonable explanation for this behaviour.
1) a bug in httpwatch.
I use httpwatch version 3 and assume that Michael uses the latest version 7. which would be quite a long distance for an unfixed bug in httpwatch
2) a bug in httpfox
As it is a new firefox plugin to me I can´t exclude it from my list of possible explanations
3) a bug in IE
Our comanys standard browser is IE6. I also assume that Michael uses the latest IE Version but with IE-way of interpreting web standards you´ll never know
What are the results of your analysis?
Thank you for pointing to this free version - I was able to install it and reproduce the problem.
You are right, that's prototype.js causing these issues, here's their code:
document.write("<script id=__onDOMContentLoaded defer src=//:><\/script>"); var contentLoadedScript = $("__onDOMContentLoaded");
Looking at prototype.js 1.6.1, I can see they are using different code: http://prototypejs.org/assets/2009/8/31/prototype.js , detecting dom readiness by polling scrollLeft property of document (see fireContentLoadedEvent function).
Keeping in mind that there are no more planned releases of 3.x version, possible workaround can be patching prototype.js script by taking code from 1.6.1.
Thank´s a lot for your investigation. I will try the workaround you mentioned and provide feedback after my tests are finished.
Hopefully changing the prototype.js wil solve this issue and won´t put up new ones.