Mac said:
Vanguardx, thanks for all your effort in this.
See the problem is not that javascript is not working just that it
seems it no longer wants to be recognized as a valid protocol.
in othe words: if I have a browser window open to an html url and I
type "javascript:alert("hello world");" into the address bar I get
the expected behaviour. If I create a url shortcut and have the url
as the same thing "javascript:alert("hello world");" it does not
work. This is compared to all my javascript url shortcuts that did
work before sp2.
Just try it type "javascript:alert("hello world");" into your address
bar and press enter. You will get the appropriate behaviour however
if you try to add this to your favorites it will only add the last
webpage and not the javascript? with sp1 it would just add the
javascript as a favorite shortcut.
Something in HKEY_CLASSES_ROOT\PROTOCOLS\Handler\javascript is
different and I don't know what.
I don't remember how I added it before applying SP-2, but I currently
have a Javascript defined as the shortcut under my Links folder (under
Favorites). When I try it now, I have to lie about what type of
shortcut that I am creating. I open the Favorites [sub]folder,
right-click to create a shortcut, and then enter some URL, like
http://whatever. That is because it bitches that "javascript ... file
not found" if I try to enter "javascript: ..." (because the
"javascript:" prefix is seen as a URL scheme). Then I change the
properties of the shortcut and replace the URL with the Javascript line
and it works then.
I don't think the Favorites -> Add to Favorites cares about open dialog
windows or whatever is in the Address bar. It is probably picking up
the URL for the current page from its history cache or some internal
variable or buffer. That's what gets added when you use the menus to
add a site to your Favorites. I've even seen where a CGI script
modified the contents of the page but the saved URL won't have the data
so when you again visit that URL then the page is wrong.
So open the Favorites folder, right-click in it to add a new shortcut,
define whatever you like but it has to be a URL or filespec, and then
change the property of the target URL to be your javascript line(s).
You'll get a prompt saying "The protocol 'javascript' does not have a
registered program". Just say yes to save the changes, anyway.
So, yeah, something changed, but it looks like IE decided to be more
compliant by actually checking if you ever installed an independent
Javascript intepreter which would get the "javascript:" protocol prefix
assigned to it. After all, "javascript:" is not an RFC 1738 defined
protocol identifier. In fact, when I search at rfc-editor.org on
"javascript", no hits are found. Since Javascript was a Netscape
invention, maybe Microsoft is weaning themselves away from it. They
probably want to use Jscript or the newer C#
(
http://msdn.microsoft.com/net/ecma/).
"Since ECMAScript is the emerging standard for JavaScript, ..."
(
http://msdn.microsoft.com/library/d.../en-us/dninstj/html/ecmascriptterminology.asp)
"This ECMA Standard is based on several originating technologies, the
most well known being JavaScript (Netscape)
and JScript (Microsoft)."
(
http://www.ecma-international.org/publications/standards/Ecma-262.htm)
What I found in the registry (I also have WinXP SP-2 applied) was:
HK_ROOT\JavaScript[1.x]\CLSID
has data item
"(default)" = {f414c260-6ac0-11cf-b6d1-00aa00bbbb58}
So I looked up the ClassID to find:
HK_ROOT\CLSID\{f414c260-6ac0-11cf-b6d1-00aa00bbbb58}
has subkey
InprocServer32 = jscript.dll
Actually this looks a little different on mine because I have Norton
Internet Security and Norton Anti-Virus installed and these intercept
scripting definitions in the registry, so you'll see Symantec's
scrauth.dll listed as the "(default)" data item and the data item
"ScrAuthInProcServer32 = jscript.dll". So it looks like Microsoft is
using their jscript.dll library to handle the Javascript interpretation.
Hmm, if you are also using NAV then try disabling its Script Blocking
function to see what happens.
By the way, I did find a "javascript" protocol definition under:
HK_ROOT\PROTOCOLS\Handler\javascript
with data item
"(default)" = {3050F3B2-98B5-11CF-BB82-00AA00BDCE0B}
and a classID lookup showed:
HK_ROOT\CLSID\{3050F3B2-98B5-11CF-BB82-00AA00BDCE0B}
has subkey
InProcServer32 = %SystemRoot%\System32\mshtml.dll
which merely shows that the HTML rendering engine from IE is the
interpreter (or front end to whever it might pass it off).
Since both Netscape (who submitted their Javascript for ECMA
qualification) and Microsoft (for their JScript and C#) are wandering
towards an ECMA qualification, guess what I found in the registry?
HK_ROOT\ECMAScript\CLSID
has data item
"(default)" = {f414c260-6ac0-11cf-b6d1-00aa00bbbb58}
which bring us back to the jscript.dll file. If the IE Repair Tool or
even a Windows CD Repair won't fix the behavior back to what you expect
then maybe Microsoft has changed that behavior. I'm sure Microsoft
never really appreciated having to support a scripting language that it
didn't define, that wasn't committee or Internet community developed,
and relied on whatever Netscape wanted to define. As with Netscape not
supporting Microsoft's ActiveX (except maybe with a plug-in for
Mozilla), Microsoft probably doesn't want to support Netscape stuff.
After all, they are still somewhat considered competitors in the browser
market. I suppose Microsoft got burned by Sun in trying to support Java
so they don't want to get in the same position with Netscape maybe
yanking away Javascript so they're looking to a standards-defined
scripting language that frees them of any Netscape whims.
