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
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.
On firefox browser, the document.write() method is not working. I also tried with document.open() and document.close() but it did not work.
<script type="text/javascript">document.write("hello");</script>
There is nothing wrong in terms of syntax with that code as I just tried it and it definitely works fine. Chances are the problems you're having are more fundamental rather than language specific.
Although the document.write function is javascript you have wrapped it in a script block which is an html element. In order for this code to run in Firefox or any browser for that matter, you'll have to save it as an html file before you can open in a browser.
you can try:
document.body.innerHTML="hello";
In Safari 5.1.2 on OSX
Tech.li is completely broken.
Some people mentioned an extra div tag being the cause, but that still didn't fix the issue.
Any help would be greatly appreciated!
Pretty basic: fix your xhtml errors [Invalid] Markup Validation of tech.li - W3C Markup Validator (scroll down in the validation report to see line numbers and source code). And use Firebug with Firefox, or in Chrome or Safari or IE8, use the developer tools to find and fix the javascript errors.
I just completed a site: http://www.justcelebrations.co.in . I haven't launched it yet because of certain problems. The site uses css3 text gradients to style text in span and border radius to style most divs. It has to be made dynamic later so I don't want to change the text effects to images or something. The problem I am facing is that the site hangs IE8. I haven't tested it in lower versions of IE. I have tested the markup thoroughly and its validated and the css too is valid except for features which are from css3 like opacity, border-radius etc. I have also added google script to make ie behave properly and mordenizer library. The site still hangs IE8. Please Help me out here..
EDIT: after a lot of testing and debugging, found out that ie<9 were crashing because of some text elements being styled by p:first-letter or h1:first-letter (which, as is the case with ie, is totally random as :first-letter is supported by IE7+ ). So all i did was separated those styles from base.css to a non-ie.css and loaded that file with a [if ! lt IE 9]
and it worked!
after a lot of testing and debugging, found out that ie<9 were crashing because of some text elements being styled by p:first-letter or h1:first-letter (which, as is the case with ie, is totally random as :first-letter is supported by IE7+ ). So all i did was separated those styles from base.css to a non-ie.css and loaded that file with a [if ! lt IE 9] and it worked!
Can you add <!--[if IE 8 ]><html class="ie ie8" lang="en"> <![endif]--> to target fixes. As you make changes view in IE8 through IE9(F12) and play with -ie-(compared to -moz- & -o-) in your css. I would also keep a CSS 2.1 file and a CSS3 file to keep track of your new code.
It's working good here in Safari. Just to narrow this down, what if you remove all the conditional and IE specific libraries you got from Google? In my experience, all the various JS libraries that are supposed to make older IE versions behave always seem to break or conflict with some other script or library like jQuery.
Also see the answer in this thread for optimizing your page loading by placing the JavaScripts at the end of the <body> section. Perhaps in your case, loading the JS last will make some kind of difference to Explorer.
I'm running Selenium in singleWindow mode and IE8.
If i start IE8 manually the IE8 mode is set, but when i launch it with Selenium, the mode set is IE7 using the compatibility mode.
Anyone knows why the compatibility mode is not the IE8 view when launching the browser with Selenium?
Or, how can i disable totally the compatibility mode in IE and force it to use always the IE8 view?
I've given the question a +1 because it's a very good question -- it's not obvious how to do this, and if you need to test both modes, then it is a necessary thing to do.
You could get the site to serve <meta http-equiv="X-UA-Compatible" content="IE=7" /> within the page when running the tests. This should force the output mode.
Obviously, that's not ideal, because it means changing your code to produce the meta tag on demand. I'd normally consider it a bad thing if you're having to change the main codebase in to add code for the specific use of your test suite, but in this case I can't see any other solution.
Given that we've decided to go down this path, you could write your code to accept a specified argument in the URL that triggers the meta tag to be served. The IE7 tests could then be written to send that URL argument.
By the way, it's worth pointing out that IE8's IE7-compatibility mode is not 100% identical to IE7; it has its own quirks and bugs which are distinct from those of a real IE7 browser. For the most part it should be fine, but it's worth being aware of this if you're expecting your tests to confirm that the site works in IE7. See this blog post for more info
I have some workarond solution for this, I use it regularly:
In internet explorer goto:
1. Tools / Compatibility view settings.
2. At the Add website input textbox add your website url.
Hope that helps, best regards,
Peter Nadasi (HUN)