Welcome to WebmasterWorld Guest from 18.206.194.210

Forum Moderators: open

Message Too Old, No Replies

Javascript:ol() and IE problem

Link Won't Open

     
4:35 am on Sep 10, 2005 (gmt 0)

New User

10+ Year Member

joined:Sept 10, 2005
posts:5
votes: 0


This problem was reported back on May 21 by Dave60 ... last reply 8:08 AM June 12, 2005. Last suggestion was to apply all IE updates. No responses after that.

To restate the problem:
Several web pages (I have two specifically not working), or for example Microsoft's own hotmail site for html e-mail, contain javascript of the form

<a href="Javascript:ol('http://blah blah');" etc. </a>

Recently, for one user these links stopped opening when the user left clicks on them. If the user right clicks on the link, and chooses Open in New Window then everything inside the " " appears in the Address bar with a 404 message. If the part inside the ' ' is pasted into the address bar, then the page can be opened normally. If the script debugger is enabled, then when the link is left clicked the debugger executes, and displays everything inside the " " as the offending command. Sometimes an error message with error "Expected Object" is displayed, but often no error message appears. When Run is selected in the debugger then the 404 error appears.

OS is Win 2K, all updates applied. All Microsoft IE updates have been applied also. IE version is shown as 6.0.2800.1106.

MS KB article 185372 seems to describe a similar admitted IE bug with the anchor tag and the Javascript OpenWindow function -- no fix available (of course). KB 281679 describes a similar problem and attributes it to a mangled Registry entry or dll, but all of the fixes listed in 281679 have been applied/checked without changing anything. I have not reinstalled IE, because IE code does not seem to be the problem ... see next paragraph.

Now the really interesting thing to me, and the reason that the IE code does not seem to be the problem, is that if I logon to the same machine as Administrator, and visit the same hotmail messages, and click on the same links, then under those conditions everything works perfectly as it should.

Since the only difference between the two conditions (I think) is the Registry, then it must be the problem. However, I haven't seen anything like this before. Maybe I am missing something.

1) Has anyone else seen this problem, or similar? Have you cured it? What worked?

2) Does anyone have any ideas about what in the h___ might be going on here?

Thanks.

1:00 pm on Sept 10, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 14, 2004
posts:1181
votes: 0


ol() is not a standard, intrinsic JavaScript method, meaning it has to be a function loaded as part of the page or as an external .js file linked to the page through a script tag with an src. It is likely the dysfunctional pages' problems relate to the code or link being broken.

Why it would affect one system and not the other is an interesting question. It is not impossible that it may have to do with cookie settings.

I think it is unlikely that the registry is the source of the problem.

6:23 pm on Sept 10, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 15, 2004
posts:2047
votes: 0


I had a look around to see what ol() i/does. I find references to it, but only in passing.
What is it? Some part of an API for MS Outlook?
11:59 pm on Sept 10, 2005 (gmt 0)

New User

10+ Year Member

joined:Sept 10, 2005
posts:5
votes: 0


Thanks, Bernard and <sorry, I'm terrible with names I've seen only once>,

A bit more information ... it appears to me now that the ol() function is something that hotmail provides (or inserts) to wrap around e-mail html references, perhaps so that they can check them for malware and perhaps add their own header to the returned page concerning how to get back to hotmail. I would guess that ol is for "open link". The function is not defined in the page (per view source) in question, so (I think) it must be server-side, or (I think less likely because of the data that the function could need) maybe it is defined in some file they have included by reference (will have to take a closer look at that part).

Also, I have found that other links on the page which do not go to external sites, but which implement navigation functions on the page (like My Account, Options, Help, etc.) also do not work. These are all implemented as Javascript calls to various functions.

By the way, a clearer description of exactly what happens when you click on one of the non-working links is "exactly nothing", as though no click was made on the link.

It looks to me now like Javascript is completely disabled for this user. However, I have been through the Advanced settings tag in Explorer, and it is enabled there, along with everything else that seems like it might apply to the situation (although I'm open for suggestions of things to check).

Another thing that I noted is that Explorer seems confused about what zone it is in, and reports Unknown Zone (Mixed) in its little lower right corner status box. I would think it should be pure Internet zone, since hotmail is not on any of the special site lists.
That reminds me that I should check this behavior under the other (working) user login.

With due respect, yes, it could be some sort of cookie problem, I agree. However, with so much stuff hidden away in the registry, and after the MS KB281679 problem report that attributed that failure to open to registry problems, I am still suspicious of some very rare, but essential, mangled value in the registry for the one user account.

Thanks for taking a look at this, those of you who have. I would really, really, like to not only make this work, but also to understand the dynamics of what is happening here.

12:59 am on Sept 11, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 15, 2004
posts:2047
votes: 0


Ah..

Here's what

ol
looks like:

function ol()
{
window.open(u, blank)
}

1) Go to a Hotmail message and write this into the browser's address bar:

javascript:alert(ol);

I went to Hotmail afterwards using FF with JS disabled:


JavaScript required to sign in

The Microsoft Passport Network requires JavaScript to sign in. This web browser either does not support JavaScript, or scripts are being blocked.

What are they on?

7:01 am on Sept 11, 2005 (gmt 0)

New User

10+ Year Member

joined:Sept 10, 2005
posts:5
votes: 0


So, the ol() is not doing too much. And it is not checking for anything, as I thought that it might be doing.

I think now, from seeing the other javascript calls that don't work also (on the same page), that this is not a problem associated with the particular routine being called.

Also, I found that calls to more complex functions, made on ~~other~~ web pages on other sites, do work for this userid. So, the problem seems like something local to the page(s) on hotmail, rather than something global for that userid. However, it is strange how the same page can work ok for a different userid on the same PC, consistently. Also, why did this problem only start happening a few days back suddenly for the one userid. Strange.

So, how could javascript be getting sort of "turned off" on certain particular web pages for a particular userid?

I have made a copy of the complete html for one message (about 26KB), under both userids, and have also downloaded the file that they are including (where the ol function is defined, among many others). Actually they are including 3 files at that point. Like this:
<title>MSN Hotmail - Mensaje</title>
<link rel="stylesheet" href="/cgi-bin/dasp/ES/hotmail___1000000002.css">
<script language=JavaScript src="/cgi-bin/dasp/ES/helppane___9080000001F.js">
</script>
<script language=JavaScript src="/cgi-bin/dasp/ES/hotmail___1021000204.js">
</script>

The ol() function is in hotmail___1021000204.js. You may have noticed from the above that this user's hotmail account is set up to use Spanish. However, that same hotmail account was used from both the local working userid, and from the local non-working userid.

The web pages are formatted a little differently, in terms of new-lines, comparing the pages served to the two different userids, but appear to be the same (without an exhaustive comparison), as one would expect. Also, the included file is the same file from the same web address for both pages.

I ran across a different thread, where someone found that the reason he was getting a similar error, and no action on a link click was because, in the declaration of the subroutine being called for that link, the prior routine had a mistake in the coding of its terminating </script>, so that the intended routine's source code was not being recognized correctly at declaration time. However, I don't see anything like that in the source for this e-mail web page, nor in the second .js file that it includes.
I haven't checked the first included file, nor done any really exhaustive syntax check on the second file. I've merely eye-balled the second file contents a bit.

If the problem is inside hotmail, and not something on the local machine, then something inside the second .js file could be confusing the parser so that some routines, such as ol() perhaps, are going un-declared when that file is parsed. However, the IE script debugging feature doesn't complain until the link using ol() is actually left clicked. However, that leaves a lot unexplained, like the recent start of the problem, and the other unaffected userid.

One thing there, is that the administrator has "Clear temporary files at exit" enabled in IE, and the problem userid has that disabled. However, I have also manually cleared the temporary files for the problem userid, and it seemed to have no effect on the problem.

Well, enough for now. Interesting how the focus of "blame" has shifted from a single non-working function to scripting in general being in-operative, in the context of these particular conditions, for one or more functions.

1:12 pm on Sept 11, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 14, 2004
posts:1181
votes: 0


I notice the src on the script tags uses a relative path. Perhaps by specifying Spanish, the user is directed to a different directory, rendering that path invalid.
4:00 pm on Sept 11, 2005 (gmt 0)

New User

10+ Year Member

joined:Sept 10, 2005
posts:5
votes: 0


Hi Rambo,

For the second script file, at least, the one containing the called ol() function, I have copied out the path and successfully downloaded the .js file. So I think the path is working OK.

However, I think I recall something about an IE bug with relative paths and (bChk=1) in the MS knowledge base, and need to go back and research that again, given the current knowledge of the problem.

Thanks for the lead.

6:22 am on Sept 13, 2005 (gmt 0)

New User

10+ Year Member

joined:Sept 10, 2005
posts:5
votes: 0


Problem finally resolved, without really knowing for sure what was wrong.

1) I re-installed Internet Explorer 6 SP1 (8MB of download)

2) Re-installed the security updates needed to bring it up to date (31 MB download; there must be a message in that number).

(I also updated my DirectX version while I was at it, but I don't think that counts for anything here.)

Still hotmail messages with Jscript content were not working! Clicking on some links that used Jscript did nothing. Other links that also used Jscript were working OK on the same web page.

Went back to MS Support site and reread KB904216, dated August 16, 2005, on the topic of IE 6 not working on some pages with active scripting (i.e. VBscript or Jscript), if the scripts had been all or partially compressed. They suggested 2 possible workarounds: 1) try completely reloading the page with a Ctrl-F5, and/or 2) Empty the IE temporary files and try reloading the page.

I retried the Ctrl-F5 on the hotmail page displaying the html message with the scripting that was not working. All of a sudden the non-working links started working. I wonder if the fairly large (about 26KB) Jscript file needed by hotmail finally made it into the cache successfully? I don't know it if was compressed; I don't think that it was, since when I successfully downloaded it from hotmail for examination, I did not have to uncompress anything.

Maybe this explains why the pages always worked for the machine Administrator who had the "remove temp files at exit" flag set in IE, but didn't work for a user who did not have that flag set in IE.

(I previously had cleaned out the user's IE temp files a couple of days ago, when I read this IE bug report the first time. At that time, before the IE re-install, the Ctrl-F5 did not seem to do anything to resolve the problem. Maybe I used it on a different page back then, or something.)

So far at least, IE now seems to be working again for other hotmail messages that use Jscript as well.

Thanks, Rambo and Bernard for your ideas and support while trying to resolve this strange problem.

1:22 pm on Sept 13, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 14, 2004
posts:1181
votes: 0


That is pretty strange. I doubt it's much consolation, but you have reinforced my satisfaction at having left MS behind; 3 months now MS-free on Xandros Linux. Life just doesn't get any better (well, online anyway).