Welcome to WebmasterWorld Guest from 18.104.22.168
Forum Moderators: open
To restate the problem:
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.
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?
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.
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).
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.
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.
1) Go to a Hotmail message and write this into the browser's address bar:
I went to Hotmail afterwards using FF with JS disabled:
What are they on?
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.
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">
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.
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.
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.