Forum OpenACS Q&A: Re: Strange browser behaviour with xowiki page containing javascript

Richard, if the javascript is called onload, then it's best to have it loaded on the page before the call, such as in the title to avoid load timing issues.

cheers,

Torben

Torben,

Good point, this is the point of the template::head::* procedures. Maybe there is a way to attach script behavior from within an xowiki page and add it to the document head.

Dave, if a javascript file is referenced as indicated above, it is included in the document head.

Certainly, when the script is timing sensitive (which should be avoided), this could be the problem, since the redirect might change the timings. The same problem will appear with with redirects on all kind of pages, independent from xowiki.

Gustaf, Torben, Dave,

Thank you for the replies. I am sorry I haven't replied sooner but have been away for a few days (actually I went to NYC to be married!). 😊

Had a lovely time.

A couple of days after posting this I discovered that I could reproduce the fault by repeatedly refreshing the browser without logging in. This ruled out the redirect as the source of the problem. I also established that the behaviour was similar but not identical in different browsers.

I came to the conclusion that the issue was a timing issue whereby my script, once in the cache, was running before the document was finished loading. This provisional conclusion was strongly reinforced by your comments.

I imagine that differences in caching behaviour between the browsers is the reason for the slight differences in effect, and the automatic setting for the cache in Explorer probably accounts for the corrective effect of refreshing the page.

I initially thought that the YUI core loader would call my function once the page was loaded, but of course it calls the function as soon as all the required YUI components are loaded, which on a second page request would be very soon indeed and almost certainly before the DOM is fully populated.

I will add the appropriate onload trigger to the page and I expect that to solve the problem.

Thus it appears to be a completely non-openacs question after all, for which I apologise!

R.

I have done more work on this and am now satisfied that there is indeed an openacs issue here. I think there were two problems. I have now eliminated the obvious one of the two.

I have triggered my script using:

Y.on("domready", myScript);

...so the timing issue has I think been eliminated, and certainly IE, Firefox and Safari all now render the page correctly on the first request and continue to work regardless of the number of times I refresh.

HOWEVER,

...taking Firefox as a good example:

http://192.168.0.100:8000/xowiki/home

[Page renders correctly, my script runs]

https://192.168.0.100:8440/register/?return_url=http%3a%2f%2f192.168.0.100%3a8000%2fxowiki%2fhome

[Log in proceeds but script does not run on re-direct. No Javascript errors shown and script tags on page appear identical.]

**REFRESH**

[No change]

**REFRESH**

[No Change]

**REFRESH**

[No change]

**REFRESH**

[No Change]

http://192.168.0.100:8000/register/logout

http://192.168.0.100:8000/xowiki/home

[My script fails to run!?]

**REFRESH**

[Page renders correctly, my script runs]

____________________________________________________________

With IE8 the picture is slightly different:

http://192.168.0.100:8000/xowiki/home

[Page renders correctly, my script runs]

https://192.168.0.100:8440/register/?return_url=http%3a%2f%2f192.168.0.100%3a8000%2fxowiki%2fhome

[Log in proceeds but script does not run on re-direct. No Javascript errors shown and script tags on page appear identical.]

**REFRESH**

[Page renders correctly, my script runs]

http://192.168.0.100:8000/register/logout

http://192.168.0.100:8000/xowiki/home

[My script fails to run again!?]

**REFRESH**

[Page renders correctly, my script runs]

There is something that these browsers don't like about this. Could it be the temporary redirect to https for the login and then the switch back? I have considered the Javascript 'same origin' policy as the problem but if the browser is caching the script for the redirected page, it surely must think the origin is the same?

Could it be that we need to fully qualify the url for the script in the header script tag? I tried to exploit the fact that urls containing a question mark are not cached but when I rename my javascript file to end with a ?, xowiki substitutes a character code.

I don't really want to have to direct that the whole page is not cached because there are images that I would like cached. Does anyone have any insights?

Regards
Richard

can you run the whole setup with either only http or only https?
I switched off the https redirect but that resulted in the same behaviour. With Dave's comments in mind, I then studied the event triggers again and discovered that there was indeed still a timing issue resulting in a completely silent failure of the script. It was running, it was just finding nothing!

Beginner's incompetence I guess. At least now I realise just how evil this Javascript monster can be! 😊

Thank you very much for your comments and help.

Regards
Richard