We Keep Coding

Very strange corner-case behavior in Internet Explorer 8 on BestBuy's website

I found a bug on bestbuy.com in IE8 and I cannot seem to understand why it occurs. It also occurs in IE8 on sites such as comcast.com and raymourflanigan.com, but not on google.com or godaddy.com.
The following code throws a "Invalid procedure call or argument" error (specifically the last line is what throws the error):
var p = document.createElement("p");
var holder = Element.prototype.appendChild;
holder.apply(document.body, [p]);
This is very strange because I've tried it in other websites in IE8 and it works like a charm. I tried using .call instead of .apply, and even storing a reference to the original appendChild method to another variable on the Element prototype, but both of these attempts threw the same error.
What is causing this?

edit
"What kind of code could possibly cause this error?"
It would seem that the error is related to the document.body not being available as a result of the page being in strict mode. The mode is entered at bestbuy as a result of the directive:
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1">
With regards to internet explorer, the option chrome=1 creates a Google Content Frame (GCF) will force the page to operate in strict mode. comcast.com is in strict mode as a result of its doctype header using XHTML.
There are various ways to enter document modes in IE
The net result of the page being in strict mode is that the rendering surface becomes available at document.documentElement. This code will append text and a paragraph at the bottom of the viewing area:
var p = document.createElement("p");
p.innerHTML = "APPEND";
var holder = Element.prototype.appendChild;
holder.apply(document.documentElement, [p]);
I made this fiddle in order to test this behavior: http://jsfiddle.net/LAkQk/
I first decided to test this behavior in multiple browsers.
Runs without error in chrome, firefox, safari, and IE8.
Note that to test this fiddle (or any really) on ie8 you must use /embedded and then click "result".
So lets just start off with the acknowledgement that there is something on those sites which is causing the conflict.
I was able to repeat the error using IE8 on bestbuy.com, and to confirm that it did work at google.com
However, this is not an issue with apply or appendChild per say. It is specifically an issue with passing the document.body. You may test this yourself with this code at bestbuy.com:
(function(){
var p = document.createElement("p");
p.innerHTML = "APPEND";
var holder = Element.prototype.appendChild;
var d = document.getElementById("header");
holder.apply(d, [p]);
})()
Perhaps it is because of something attached to the body as a result of one of their plugins. Amusingly, this works from the ie console at bestbuy.com
$("body").append('<p>Append!</p>');
I looked through a number of the plugins and cannot find the exact line of code which is causing the overload or conflict, but it must be there, more than likely as a result of sniffing the user agent.

Debugger says "'Element' is undefined" for Travis' code and the only JS exception I receive when I load the page is that 'hasAttribute' is a not supported method. Both happens only when the IE8 loads the page in compatibility mode (Document Mode: IE7 Standards), but probably I load a different page from yours: your code uses Element so the exception would be the same as for Travis' code.
And here is the answer:
What's IE take on HTMLDocument and HTMLElement
There is no 'Element' in IE7.

Have you had problems with Dojo 1.7.1 in Internet Explorer 7/8?

I have been working on upgrading an application from dojo 1.4.3 to 1.7.1. Everything is working great in Firefox/Chrome/Safari, but IE7 and IE8 are both failing. The first failure appears to be coming from the code in dojo/ready around line 40.
try{
f();
}
// FIXME: signal the error via require.on
finally{
onLoadRecursiveGuard = 0;
}
Has anyone else noticed problems with this? Is there a work around? Dojo claims it should work in IE 6 - 9, but I have seen other comments that suggest the try/finally will break in IE without the catch. Is this true? Thanks for any insight into this problem ahead of time!

I had this problem and it was because safeMixin was called throughout my code without checking the arguments passed in. safeMixin is 'supposed' to have a valid object passed in as an argument.
This can happen up if you 'new' an object with an empty constructor and then pass the args directly into safeMixin. There are other cases as well.
Here is a bug report.

I had same problem when using JsonRest:
var jr = new JsonRest(); // cause exception
var jr = new JsonRest({}); // it works

Intermittent JavaScript Issue

I'm running some JavaScript via eval (I know, shoot me), that basically enumerates all of the properties on the document object. My issue is that while it works in firebug, it throws a not implemented exception in Firefox, when run from a script.
Link to JavaScript script, the exception thrown, and the firebug command working.
Any suggestions as to what's going on here?
For the record, this is done on Firefox 3.6.10 on Ubuntu 10.04 64-bit, and chrome does not have this issue.

The error is here:
console.log(result);
remove that line and all should be fine.
The console object is a Firebug thing (refers to the Firebug console). Safari/Chrome just happen to also implement a console object (refers to Webkit js console). Firefox, indeed other browsers don't have a console object. So it throws an error.
BTW: As usual, the evals are completely unnecessary. This is exactly equivalent code:
for (key in document) {
result[i] = typeof document[key];
result[i+1]="document."+key;
i+=2;
}
If you insist on calling it request then use it as a reference:
var request = window.document;
for (key in request) {
result[i] = typeof request[key];
result[i+1]=request+"."+key;
i+=2;
}
If you insist on passing object names by string, then for sanity's sake use eval in a less confusing way:
var string = "window.document";
eval("var request ="+string);
for (key in request) {
result[i] = typeof request[key];
result[i+1]=request+"."+key;
i+=2;
}
Though I wouldn't do even that (sometimes it is necessary, but only very rarely).

Why does CSS3Pie + Prototype 1.6.1 crash Internet Explorer 8

I'm trying to understand why Css3Pie used in conjunction with Prototype 1.6.1 crashes Internet Explorer 8. Why is this happening?
Relevant information
CSS3Pie [source code] is an Internet Explorer behavior (htc) that adds support for CSS3 properties like border-radius, gradients, etc.
The crash only happens in IE8, not IE7 or earlier.
The crash only happens in Prototype 1.6.1 [source code], not Prototype 1.6.0.x
The crash happens immediately on page load, I'm not even able to interact with the page.
The developer is aware of the issue but since he believes it is a Prototype issue (it may be), he may not be eager to fix it. There is both a forum post and GitHub bug report, but neither add much information.

This IE8 crash, which appears to have been fixed in a recent Windows update, was triggered by Prototype's tinkering with DOM object prototypes followed by the application of the CSS3Pie behavior. In Protoype 1.6.1, it can be worked around by setting ElementExtensions and SpecificElementExtensions to false on the Prototype.BrowserFeatures object and modifying the checkDeficiency function to return true immediately.

It's a good start, but then it stops working under other browsers (ie. firefox, chrome). Instead you should add at the beginning of each function (ElementExtensions, SpecificElementExtensions, checkDeficiency) a check for IE 8 then return false for the Extensions anonymous functions and return true for the checkDeficiency function.
ElementExtensions: (function() {
if (isIE8) return false;
...
SpecificElementExtensions: (function() {
if (isIE8) return false;
...
function checkDeficiency(tagName) {
if (isIE8) return true;
...
var isIE8 = (function(){
return ((navigator.userAgent.indexOf('MSIE')!=-1) && (document.documentMode==8));
})();

Log to Firefox Error Console from JavaScript

Is it possible to add messages to the built-in error console of Firefox from JavaScript code running in web pages?
I know that I there's Firebug, which provides a console object and its own error console, but I was looking for a quick fix earlier on and couldn't find anything.
I guess it might not be possible at all, to prevent malicious web pages from spamming the log?

If you define a global function that checks for the existence of window.console, you can use Firebug for tracing and still plays nice with other browsers and/or if you turn Firebug's console tracing off:
debug = function (log_txt) {
if (typeof window.console != 'undefined') {
console.log(log_txt);
}
}
debug("foo!");

You cannot write to the console directly from untrusted JavaScript (e.g. scripts coming from a page). However, even if installing Firebug does not appeal to you, I'd recommend checking out Firebug Lite, which requires no installation into the browser (nor, in fact, does it even require Firefox). It's a script which you can include into any web page (even dynamically), which will give you some basic Firebug functionality (such as console.log()).

Yes, you can =P
function log(param){
setTimeout(function(){
throw new Error("Debug: " + param)
},0)
}
//Simple Test:
alert(1)
log('This is my message to the error log -_-')
alert(2)
log('I can do this forever, does not break')
alert(3)
Update to a real function
This is a simple hack, just for fun.

window.console is undefined in Firefox 4 beta 6 even if Firebug 1.6X.0b1 is enabled and open, probably because of privilege issues that others discuss. However, Firefox 4 has a new Tools > Web Console, and if this is open you have a window.console object and untrusted JavaScript code on the page can use console.log(). The Web Console is in flux (see https://wiki.mozilla.org/Firefox/Projects/Console), you may need to change settings named devtools.* in about:config , YMMV.

I would just install Firebug and use console.log. If you can't do that, though, you can always throw an error:
throw "foobar";
throw new Error("bazquux");
Of course, this will break you out of the code that you're currently executing, so you can't use it for detailed logging, but if you can work around that I think it's the only way to get something logged out of the box.

AFAIK, it is not possible. But if you are interested in how extensions in Firefox interact with the error console, check this out.

This function does not require any extension nor library. However it grants full privileges to the relevant website. No worries since you are the one developing it, right?
// Define mylog() function to log to Firefox' error console if such a
// thing exists
function defineMyLog()
{
// Provide a useless but harmless fallback
mylog = function(msg) { };
// return; // disable in production
if (typeof(netscape) === "undefined") {
// alert("Logging implemented only for Firefox");
return;
}
// The initial auth popup can be avoided by pre-setting some magic user_pref
// ( "capability.principal.codebase.p0.granted", "UniversalXPConnect"), etc.
try {
netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
} catch (e) { // User has denied privileges
// alert(e.name + ": " + e.message);
return;
}
ffconsoleService = Components.classes["#mozilla.org/consoleservice;1"]
.getService(Components.interfaces.nsIConsoleService);
mylog = function (msg)
{
netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
ffconsoleService.logStringMessage(new Date().toLocaleTimeString() + ": " + msg);
}
mylog("Firefox logging function has been defined");
// window.open("javascript:"); // this URL does not work anymore?
}

If you're interested, check out a script I wrote -- it's a "cheap" Firebug replacement that doesn't interfere with any normal console (like Safari or Chrome) but does extend it with almost all the Firebug methods:
http://code.google.com/p/glentilities/
Look under the hood and you'll see what I mean by "cheap". :-)
Combine it with YUI or json.org's JSON serializers to sorta replicate console.dir.
Firebug and Firebug Lite are definitely nicer GUIs, but I use my home-grown one all the time to retain logging safely even for production code -- without constant commenting & un-commenting,