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

I have a schort script included in an xowiki page:

[[js:my_script.js]]

A study of the header shows the script tag correctly placed and the page loads and script runs with no errors.

HOWEVER, I cannot understand the following sequence of events:

Entering: http://n.n.n.n:8000/xowiki/page

results in a perfectly working page load.

If I then click 'Log In' the re-direct works to the registration page on the secure port as expected:

https://(n).(n).(n).(n)8446/register/?return%5furl=http%3a%2f%2f(n)%2e(n)%2e(n)%2e(n)%3a8000%2fxowiki%2fhome

....I log in and the page correctly returns to the original page, but this time my javascript file doesn't run!

If I refresh the page it then runs fine.

No browser errors are shown.

Completely baffled.

Regards
Richard

Strange, indeed. The return-redirect reloads the page (i.e. issues a fresh request). If the script tag with the .js file link appears after the login in the head, then it looks like a problem in the browser to me. I have just tried the sequence with a tiny .js file with one alert(), and it seems to work well.

I remember some strange behavior with .js caching, but that's already some time back.

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

You should install firebug in firefox or firebug-lite (js bookmarklet) in IE and put some debugging statements in your ready handler to find out exactly what is happening.

Most likely you are hitting a silent error in the javascript code.

can you run the whole setup with either only http or only https?
Dave,

Thanks for the reply.

I have already tried Firebug which shows no errors. I have also tested the event handler is being called by adding an alert. All works fine. The script takes no data and either works or doesn't. The page data on which it operates is unchanged.

A silent Javascript error could well be the problem, but what I can't understand is why it works just fine when the page is requested over http://ip:port, but fails on redirect after logging in to openacs.

I will try removing the https component of the issue as Gustaf suggested, and will also replace the script with one that doesn't call any YUI3 components. (I have the yui-min.js included as [[js:yui-min.js]] in the xowiki::Form and am relying on it to autoload the component files for me from Yahoo. I did this because referring to the yui-min.js file from the Yahoo url in the formpage didn't work.)

When I previously had problems sourcing YUI components I saw errors in the IE console and Firebug, but this time I get nothing.

Regards
Richard

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