We Keep Coding

Browser component (IE) does not show values for document.getElementbyId

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.

dojo.exists fails with IE11

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.

How do you run an xPath query in IE11?

At one point in our system we use javascript to read in a chunk of XML and then query that XML document using xPath.
Prior to IE 11, IE supported using xmldoc.selectSingleNode(“//xpath/string”) and the non IE browsers supported using a xmldoc.evaluate(“//xpath/string”). These both returned a similar object that we could then carry on interpreting to extract the data required.
In IE11 neither of these methods seem to be available.
It seems that IE11 has some support for XML documents in that when I read in the xml using the DOMParser object using the parseFromString method, it returns an object that the IE11 debugger calls an XMLDocument.

Thanks to #Martin Honnen for pointing out that some ActivXObjects are still supported in IE11!
var doc;
try {
doc = new ActiveXObject('Microsoft.XMLDOM');
doc.loadXML(stringVarWithXml);
var node = doc.selectSingleNode('//foo');
} catch (e) { // deal with case that ActiveXObject is not supported }
I've used "Microsoft.XMLDOM" as it is sugested here that it is a more generic call to what ever xml parser is present on the system, where as it sounds like "Msxml2.DOMDocument.6.0" will fail if that exact version is not present. (We do have to support all IE vers back to 6.0 at my place!)
This just works as it always has done. The only problem I had was that the old switch I used to detect IE vs other browsers was if (typeof ActiveXObject !== "undefined") failed as I guess they are trying to discourage it's use!
Thanks all for your help.

To expand on pixelmatt's answer, some results of my tests (Win 7 64bit with IE11) I did in order to get DOMParser to work as it did in IE9 and IE10 (in IE11 it now returns an XMLDocument object which appears to not support xpath queries?).
Turns out I could make it behave like in IE10 with the following meta tag:
<meta http-equiv="X-UA-Compatible" content="IE=10" />
Results without and with above meta:
And here are the XMLDocument's memebers (for reference):

How to get browser "Document Mode"

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.

Check webkit version with javascript embedded pywebkitgtk?

Apparently the best way to check the version of webkit is
/AppleWebKit\/([\d.]+)/.exec(navigator.userAgent)
(as seen here and a few other places). What is this /AppleWebKit/, a hidden variable, a constant, a regex?
I noticed it worked fine in the browser, but would not work in an embedded pywebkitgtk, it returns null. Is there something missing in the embedded webkit?

/AppleWebKit/([\d.]+)/ is a regular expression which navigator.userAgent is checked against.
The navigator object returns information about the browser you use (name, version, etc). So I guess this does not exist in pywebkitgtk, as it's only a framework for WebKitGtk, not a browser by itself.