Opera and the Open Statement - A Solution

Opera is a much smaller browser than Internet Explorer or Netscape in that it takes up a minute fraction of the hard disk space of either of the two major competitors. This makes it a good alternate browser but its small size unfortunately means that some things don't work quite the way you expect based on experience with the other browsers.

One of the things that I have not seen work properly in Opera 4, Opera 5, or Opera 6 is the Javascript open statement. In Opera 4 simply coding a document.open statement is enough to crash the browser and I still have not discovered a solution to that problem. Fortunately, with Opera 5 that problem has been fixed so the browser no longer crashes however the Opera 5 browser when generating a page to appear in another window using window.open, the relative image references and links in the generated page fail due to having lost track of the URL that the addresses are relative to. Opera 6 fixes this problem but now generating a new page to display in the existing browser window using document.open suffers from that problem instead.

When I first noticed this problem with Opera 5, it didn't worry me too much because the only item on this web site affected by this is the logo on the javascript generated pop under window discussed on the Creating a Pop-up or Pop-under Ad Window page. With Opera 6, the problem affected the javascript site search function and I was just about ready to give up on Opera and recommend that people not use it when I thought of this simple fix to the Javascript code that corrects this referencing problem in both Opera 5 and Opera 6 without affecting the way that other browsers handle the code. This last aspect is most important as it is almost impossible to identify Opera users as the browser defaults to identifying itself as one of the other browsers so as to get around the problem of so many web sites carelessly coding browser specific javascript code instead of using Feature Sensing.

The solution is actually rather simple, to use absolute rather than relative addressing on the image references and links generated by the javascript. Actually, if we were to just convert each relative address into an absolute one it would add significantly to the length of the overall code and would lock the code in with the one address (which is awkward for if you load your code to more than one URL or you want to be able to test your code on your PC before you upload it. I didn't really want to do this with my code, the search function code in particular is rather large already since it contains a large keyword to page cross reference table that would be made even larger by doing this. I didn't want to solve the problem that way as it was too messy, restrictive and required too big an overhead just to cater for one version of one browser that makes up a very small fraction of browser usage.

Then I remembered the <base href="http://www.yoursite" /> statement that I had never seen any need for prior to this time. I have already made use of the javascript code
var dir = location.href.substring(0,location.href.lastIndexOf('\/'));
in a number of spots in the javascript code on this site in order to obtain the directory portion of the site URL (mainly so that I could then subsequently check if the current page was in a sub-directory so that I can use the same javascript page footer code on both my main computer site and railway sub-site in order to remove those parts of the code inappropriate for one or the other). It finally occurred to me to try combining these two statements together and see what I could achieve by doing this. The code I came up with is as follows:

 var dir = location.href.substring(0,location.href.lastIndexOf('\/'));
var baseref="<'base href='"+dir+"/'>\n";

The first statement in this code gets the URL of the directory containing the page that is executing the javascript which can be either a folder on your computer or a directory on a web server. The second statement generates a base href statement using this information. You then incorporate this into your document.write or window.write statement that is generating the source for your new page. The appropriate place to put it is between the close title tag and the close head tag (you probably wont have meta tags in a javascript generated page but if you do, place the code after them; also place it before any script and link tags). The way to incorporate this into the write statement is indicated by statement three.

This seemed a simple solution but would it fix the problems with Opera 5 and 6. More to the point, would it work with Internet Explorer and Netscape and would it work on a PC as well as on the web site? I proceeded to test this code change with both of the pages that I mention above as having a problem. Testing with Opera 5 and Opera 6 on my PC showed that this code does in fact fix the referencing problem that these versions of Opera were having and testing with Internet Explorer 5.5, Netscape 4.7, and Netscape 6 showed that the change has no effect on the javascript processing by any of these browsers. I therefore advise that you modify any javascripts that you have that generate entire pages (either within the current browser window or in a new window) to incorporate this additional small piece of code and thus allow the generated page to display and function correctly in Opera 5 and 6 as well as the other more commonly used browsers.

Postscript: Its a pity that free web hosts have a block on their web hosting that stops this fix from working with sites hosted on free sites. Free web hosts have a block in place to stop remote loading of images so as to stop people stealing their bandwidth. This code isn't actually remote loading images but uses code that the web host interprets as remote loading when your visitors use Opera 5 or 6. I still recommend including this code even where you host your site somewhere where it doesn't work as you may eventually want to move your site to a web host where this fix will work and you are at least no worse off with the fix in place than you were before.


This article written by Stephen Chapman, Felgall Pty Ltd.

go to top

FaceBook Follow
Twitter Follow