I am developing some kind of JavaScript library. And i cause the problem that i have some specific issues for:
Browser : IE8 / IE9 and Document Mode : IE7
I found the solution, but i don't want to use it in all situation, and want to use it just when i have the situation described above. I know that I can recognize browser by using:
return navigator.userAgent.toLowerCase().indexOf('MSIE 8') > -1;
But i recognize just browser version in such way but not the document mode, and i don't want to use my solution when I have, for example, browser mode IE8 and document mode IE 8.
Is there a way to get page document mode in IE? Thanks in advance.
You can use document.documentMode to return exactly what document mode IE is using.
Meaning that if you have your browser mode set to IE9, but your document mode to IE8 it will return document.documentMode == 8 (while the userAgent string will still show up as IE9). This is particularly useful if your JS ever includes styling changes as it is the document mode that determines how IE renders a page, not the browser mode. Compatibility mode really just changes the document mode (usually to IE7).
In the few cases I've needed to I've just used something like this to differentiate IE's:
if (document.documentMode == 7) {
doSomethingIn.IE7_only;
} else {
doSomething.everwhereElse;
}
Hope that helps some.
I don't know how to retrieve the document mode1, but it may be wise to address the problem in a more basic way. Let's say you wanted to use document.querySelector in your scripting. That would fail in IE8/document mode IE7 Standards. So an additional check for the existence of document.querySelector itself would be the solution:
return ~navigator.userAgent.toLowerCase().indexOf('MSIE 8')
&& document.querySelector; //=> IE8 and Docmode IE7 => false
1 Found a way to check for document mode: use document.documentMode. It returns an integer (so 7 for document mode IE7 standards), 5 for Quirks mode. It will be undefined for non IE browsers.
Related
I am listening to a server event via a javascript function on my HTML file, which outputs the server answer in the console tab. Since I need to pass this answer to a delphi application, I made the server answer "visible" via a div container. This works fine on Firefox, but on IE the output is not shown. I have then tried to utilize the value of a textarea, which also works on Firefox but not on IE.
I really wonder why it is so hard to get a console output visible on IE?
document.getElementById('my_div_container').innerHTML = JSON.stringify(my_data_I_want_to_see, null, 4);
document.getElementById('my_textarea').value = JSON.stringify(my_data_I_want_to_see, null, 4);
The above lines show a result on Firefox, but on IE there is no output at all. How can I get my data visible on IE?
I found the root cause why IE did not show any console output. I just found out, that the addEventListener() method I was using is not supported in Internet Explorer 8 and earlier versions.
I am very sorry for any confusion.
If you are using TWebBrowser component in Delphi for displaying the webpage do note that by default it running in Internet Explorer 7 compatibility mode.
In order to avoid this you need to opt your program into browser emulation feature
How to have Delphi TWebbrowser component running in IE9 mode?
Don't forget to check MSDN documentation for proper registry value to enable emulation of most modern IE versions.
Since a few days, I have troubles with Internet Explorer 11 in conjunction with dojo toolkit 1.9.4 hosted by a Domino Server.
Source Code:
if (dojo.exists("btnUpload")) {
console.log("btnUpload exist ... do something...");
} else {
console.log("btnUpload doesn't exist...");
}
With IE11 the return value of dojo.exists() is always false!
IE11 Debugger:
However in all other browser (Mozilla Firefox, Google Chrome, Apple Safari) it works!
Using dojo.exists for this isn't very appropriate, given that btnUpload is technically just a DOM ID, and not an actual object in the global scope. if (document.getElementById('btnUpload')) would seem to be far more appropriate in this case.
When a global reference is encountered that doesn't match an actual global variable, but does match a DOM ID, browsers tend to return the DOM node, but I wouldn't recommend relying upon that.
So I've got this code that runs inside a HTA...
jsv=ScriptEngine()+' v'
+ScriptEngineMajorVersion()+'.'
+ScriptEngineMinorVersion()+'.'
+ScriptEngineBuildVersion()
It displays the version of JScript the HTA is using.
So... My question is:
Can I display the IE Compatibility Mode version, or similar, of the HTA in the same way?
And if so... How?!
In IE8 and later, you can retrieve document.documentMode. It gives you a number representing the current document mode, 5 for quirks-mode, 6 for IE6 etc.
In IE6-7 there was document.combatMode, which returned a string telling you whether the standards-compliant mode is switched on or not.
Notice, that ScriptEngine returns the latest available JScript version, the used document mode doesn't change the values.
var isH5 = !! document.createElement('canvas').getContext
Would you say, that above JS code snippet is a good method of recognising a Browser's HTML5 capability?
Also see What is the !! (not not) operator in JavaScript? in case of IE quirks mode, it should still return false.
Update: Thanks for all the Modernizr links, we are using above recognising logic in conjunction with Modernizr already.
The better solution is to use something Modernizr to detection .Modernizr is an open source, MIT-licensed JavaScript library that detects support for many HTML5 & CSS3 features. If there isnt support, it returns false
if (Modernizr.canvas) {
// logic
} else {
// your message
}
I know this is crazy, but IE can drive one to do crazy things.
Here's the deal: we have a SharePoint 2007 site with Content Editor Web Parts. We have a contingent of users with Internet Explorer 8. We want to keep the site in IE8/IE8 Standards modes for better rendering of content. However, this configuration breaks the ability to open the Rich Text Editor window from the C.E. web part.
If we force IE8 into IE7 document mode or quirks mode, it works. Indeed, other sources online have suggested doing just that to fix the problem. But we'd really rather have everything run in standards mode.
Through some debugging, we found the source of the problem to be the use of document.all.index("<web_part_id>") JavaScript when retrieving a web part object on the page. In IE8 standards, this returns an object with most of the properties either empty, null or undefined; most notably, the id property is not set. If you were to use document.getElementById to retrieve the same ID, you get back a fully populated object. Likewise if IE8 is not in standards mode, you get back a mostly (but not completely) populated object -- but populated enough to avoid the script error, anyway.
All this code looks like it is injected dynamically into the SharePoint page, so that rules out simply replacing references to document.all. However, we got the crazy idea of redefining the document.all.item method to actually invoke document.getElementById. Our attempts so far to do this don't work, so perhaps someone might shed some light on what we're doing wrong (okay, there's lots wrong about this, but it's IE and SharePoint, right?).
Our initial attempt at an override looks like this:
<script type="text/javascript">
document.all.item = function(id) { return document.getElementById(id); }
</script>
This code is in the document HEAD, above any other script references (SharePoint or otherwise), but it does not appear to supersede the native code.
Thoughts, ideas, suggestions and criticisms welcome!
document.all is a HTMLCollection, so you may use HTMLCollection.prototype to change the behaviour:
if(document.all
&& !window.opera
&& typeof HTMLDocument=='object'
&& typeof HTMLCollection=='object')//filter IE8
{
HTMLCollection.prototype.item=
function(id)
{
return((this==document.all)
? document.getElementById(id)//document.all
: this[id]//maintain native behaviour for other collections
);
}
}
So you're saying you can't change the references to document.all.item because SP directly injects it to the html? So couldn't you use the DOM to replace it?
BTW, I feel your SharePoint pain. I've built SP workflows, and those are enough of a pain for me!