I'm trying to use Window.Location.Href in my VBScript code,
this throws me an error on Windows 7, IE 10:
Object doesn't support this property or method
It's working on XP and it's even working on Win7 if I'm using javascript.
What can be the problem?
Change to window.location.href (javascript sintax, no uppercase) and it will work.
It looks like Windows 7 IE 10 has some problems with VBScript. Can you try running your page in IE9 compatibility mode? If not then try to determine which object/property combination is giving you the problem. If Window.Location is the problem then try just using Location. However, if Location.Href is the problem then there may be a security issue going on.
More information on setting compatibility mode at vbscript is not working on IE10 browser mode
Related
I am customizing iNotes (Notes web mail client), adding some features using javascript that require ajax calls to external sources. In doing so I have found Internet Explorer won't perform CORS (cross-origin) requests. Errors are either access denied or some other security errors depending on how it's called. Chrome and FF and Safari all work.
I have found what I believe to be the culprit, iNotes adds a meta-tag to emulate IE9.
<META http-equiv="X-UA-Compatible" content="IE=EmulateIE9" />
For CORS requests, IE9 does not support XMLHttpRequest, rather you must use XDomainRequest, which was only supported in IE8 and IE9. Since it's emulating IE9, the XMLHttpRequest (or jQuery .ajax calls for that matter) don't work.
I have not been able to find any way to remove that meta tag, I did a search on the mail file and there are no matches for IE=EmulateIE9 that I could find. And I'm sure if I did remove it, I would break something in iNotes.
I didn't want to load jQuery, but may do so for this script and include the moonscript plugin which uses XDR for ie8 and ie9 browsers. If iNotes is ever updated, it will still work.
Anyone else run into this problem and find a better solution?
Lothar Mueller pointed me in the right direction.
Domino 9.0.1 Fix Pack 5 adds a Forms9s.nsf which allows you to get rid of "Quirks Mode" for IE backwards compatibility. After installing the FP, the new forms9s.nsf file is installed, then you update the notes.ini with
iNotes_WA_DefaultFormsFile=iNotes/Forms9s.nsf
iNotes_WA_FormsFiles=iNotes/Forms9s.nsf
and it eliminates the emulation tag for IE. I still have to test my iNotes customization apps, but this gives an option for running some IE features that didn't work before such as Ajax requests from iNotesExt_9.nsf, etc.
I have this simple vbscript code:
<script type="text/vbscript">document.write("hello world")</script>
However when I view this file in IE 11 on Windows 7 hello world is not displayed.
Am I missing something?
As of Internet Explorer 11, VBScript is considered deprecated and should no longer be used as a scripting language for IE11. Webpages displayed in IE11 edge mode won't execute VBScript code.
More information here: https://msdn.microsoft.com/en-us/library/ie/dn384057(v=vs.85).aspx
Error context:
Visual Studio 2010 Service Pack 1
ASP.NET MVC 3 Application
IE9 with Script Debugging enabled for Internet Explorer
Error conditions:
Execution stops int a JavaScript file called "script block [dynamic]" at the following line
doc.addEventListener("DOMNodeInserted", onDOMNodeInserted, false);
that line of code is nested inside the following if block
if (ver >= 9.0)
{
doc.addEventListener("DOMNodeInserted", onDOMNodeInserted, false);
doc.addEventListener("DOMNodeInsertedIntoDocument", onDOMNodeInsertedIntoDocument, false);
}
This is a very persistent error that started happening after I re-imaged my hard drive and reinstalled VS 2010 SP1 and ASP.NET MVC 3. I did it twice to make sure I did it right.
I am going to take a guess and suggest that this bug is the side affect of an un-handled exception in ASP.NET MVC 3 or a bug in IE9. The error seems to ocurr when a (GET?) action method cannot be found that is specified in the ActionLink HTML helper method such as
#Html.ActionLink("Link Text", "Action")
I believe that IE9 does support addEventListener so the error itself is incorrect. Unless I can get more info this error is beyond my ability to fix its cause. I can prevent it by making sure that my action method is there and that it works. That is a workaround not a fix. Fixing the error would prevent it from being erroneously reported because IE9 does in fact support addEventListener.
An answer has been found to this question. The problem was caused by the Divix browser plugin
Solution: Object doesn't support property or method 'addEventListener'
Thank you to a poster on the asp.net forums for helping to solve this problem. The Divix browser plugin has recently been updated. The update may have fixed this issue. However, it remains disabled on my system. Disabling the Divx plug-in definitely fixed this issue for myself and others. I have reported this bug to Divx support.
I've been getting this error today while working on a VS 2010 project, I was using IE9 for my browser. Turns out it's an erroneous message, I should have been getting a page not found error. I tried disabling Divx as mentioned above, but that didn't help. I then tried using Chrome and it reported my error correctly and I was able to solve my problem.
If you get this error, try a different browser which may point you in the right direction.
I turned off Compatibility Mode (was running on local intranet) and the problem went away.
Here's my JS insert:
<script type="text/javascript" src="include/profile.js"></script>
In IE8 with "Compatibility View," the file never loads. The first line in the file is a simple alert() call, so that I know it loaded. Change the browser to Standards View, and it loads fine.
Also, if I add:
<meta http-equiv="X-UA-Compatible" content="IE=100" >
It forces to Standards View and it loads fine.
Any idea why this would be the case? I've not been able to test against IE7, but I know the JS file also does not load in IE6.
Right now the tag is in the section of the file.
It would seem that IE8, Safari, Firefox, et al will tolerate certain JavaScript syntax errors. IE7 and IE6 (and IE8 in 'compatibility view') will not, and they will also not throw a parse error or any other kind of clue.
Pasting my code into http://www.jslint.com/ revealed a couple of syntax errors that weren't affecting the code's operation in other browsers. So boo on me.
Okay. Had the same problem on IE8 and safari 5 on windows and finally got this working. This one is really beauty...
I had a function with a parameter named 'class' which was causing the issue. Renaming to clsname fixed the problem. Apparently FF and chrome were lenient about this.
Turn on script debugging and see if you are getting a javascript error in compatibility mode. The presence of an error would keep the javascript from executing even if it is loaded. You might also want to use the developer tools in IE8 to debug the javascript and/or verify if the file is loaded or not.
just spent couple of hours on this - IE7 & 8 suffers from "return" identificator
I had:
m["return"] = 123;
var x = m.return; // SILENT ERROR!
Obviously, renamaing identificator solves this
Whenever I call FileUpload.Set, IE8 will open up the file browser window and just sit there without typing any text. This is on Windows XP and it used to work just fine until I upgraded from Ie7 to IE8. Anyone else run into this?
Turns out this line in the WatiN source was the problem:
if (Process.GetProcessById(window.ProcessID).ProcessName != "iexplore") return;
For some reason, the iexplore process on this machine appears as "IEXPLORE", in all caps. Adding a .ToLower() to the process name fixes the problem.
edit: looks like this bug has already been reported.
Because of the way WatiN looks for the dialog box (by style number), it's understandable that IE8 would be broken in versions less than 2.0. You may want to try it with the 2.0 beta.
Alternatively, you can dive the style numbers on the FileUpload DialogHandler and add the style numbers for IE7 and 8 (96CC20C4 and 96CC02C4).
I'd like to post an update for this problem since it came up again in Win7 OS.
If you have the same problem in the latest WatiN release you can override the function CanHandleDialog in the FileUploadDialogHandler class:
public override bool CanHandleDialog(Window window, System.IntPtr mainWindowHwnd)
{
return true;
}
It's not a clean solution but it is the simple and works.