Site behaves differently when developer tools are open IE11 - javascript

Im using the following template in IE11 and can not figure out why the sidebar sings in every time navigation is happening. When developer tools are open it behaves as I would like it to. It is easily demoed by clicking on any one of the tabs under UI element in the tree while running IE11. However you will notice if F12 developer tools are open the side bar does not slide in every time navigation happens. This is not an issue in chrome. There is an error with fastclick that may show up however I have ran without fastclick and it still happens. Any help would be great. Thanks.
https://almsaeedstudio.com/themes/AdminLTE/pages/UI/general.html

Try removing any console.log() from your code.
console.log() which is to help out when debugging Javascript can cause IE to completely stop processing scripts on the page. To add to the mystery, if you keep watching your page in IE with devtools open - you won’t notice an issue at all.
Explanation
The reason for this is the console object is not instantiated unless devtools is open in IE. Otherwise, you will see one of two things:
Javascript won’t execute correctly
Console has cryptic errors, such as ‘object is undefined’ or others of that nature
Nine times out of ten, you have an errant console.log in the code somewhere. This does not affect any browser other than IE.

Another potential cause, especially if you are performing ajax calls, is the ajax response may be cached when dev tools are closed, but refreshed from the server when dev tools are open.
In IE, open the Network tab of Developer Tools, click the play icon, and un-set the Always refresh from server button. Then watch to see if any of your ajax calls are coming back with a response code of 304 (Not modified). If they are, then you are not getting fresh data from the server and you need to update the cacheability settings on the page that is being called via ajax.

Adding onto the already great answers (since I can't comment - requires 50 rep points), agreeing with the answer from #sam100rav and the comment from #storsoc, I discovered that in IE11 version 11.1387.15063.0 with updated version 11.0.90 (KB4462949), that window.console indeed exists as an empty object (window.console = {}). Hence, I used a variation of the polyfill from #storsoc as shown below.
if (!window.console || Object.keys(window.console).length === 0) {
window.console = {
log: function() {},
info: function() {},
error: function() {},
warn: function() {}
};
}

As pointed out already it's because IE11 + Edge<=16 is so stupid that it doesn't support console unless developer tools is opened... So if you open that to disable caching you won't see any issues and you might think that the issue was just due to browser cache... but nope.. :#
I made this "polyfill" for it (doesn't really polyfill, but makes IE not throw any errors). Add it as early as possible on your site as any js might be using console.log or console.warn etc.
window.console = typeof window.console !== 'object' || {};
console.warn = typeof console.warn === 'function' || function () {
return this;
};
console.log = typeof console.log === 'function' || function () {
return this;
};
console.info = typeof console.info === 'function' || function () {
return this;
};
console.error = typeof console.error === 'function' || function () {
return this;
};
console.assert = typeof console.assert === 'function' || function () {
return this;
};
console.dir = typeof console.dir === 'function' || function () {
return this;
};
console.table = typeof console.table === 'function' || function () {
return this;
};
console.group = typeof console.group === 'function' || function () {
return this;
};
console.groupEnd = typeof console.groupEnd === 'function' || function () {
return this;
};
console.time = typeof console.time === 'function' || function () {
return this;
};
console.timeEnd = typeof console.timeEnd === 'function' || function () {
return this;
};
console.timeLog = typeof console.timeLog === 'function' || function () {
return this;
};
console.trace = typeof console.trace === 'function' || function () {
return this;
};
console.clear = typeof console.clear === 'function' || function () {
return this;
};
console.count = typeof console.count === 'function' || function () {
return this;
};
console.debug = typeof console.debug === 'function' || function () {
return this;
};
console.dirxml = typeof console.dirxml === 'function' || function () {
return this;
};
console.groupCollapsed = typeof console.groupCollapsed === 'function' || function () {
return this;
};

I'm assuming you've fixed this since you posted it as I can not see the behavior you describe in your link.
However, I have recently run into a similar issue where the dev tools being open changed the behavior not because of console issues, but because opening the tools changed the width of the window. It was the window width difference that triggered an underlying bug in my case.
Related post here.

It's possible you've got the compatibility mode set to a later version of IE in your developer console (see the highlighted section)

Related

Test overwriting console.log with Jest

I'm filtering some messages with the following code:
const consoleLog = console.log;
console.log = (...args) => {
if (args.length === 0 || typeof args[0] !== 'string' || !args[0].includes('[HMR]')) {
consoleLog.apply(console, args);
}
};
How can I test the console output of this function? Normally, I'd just mock console.log, but in this case it's overwritten by the code above, so I can't do that.
Or don't mess with the original console.log at all.
const consoleLog = (...args) => {
if (args.length === 0 || typeof args[0] !== 'string' || !args[0].includes('[HMR]')) {
console.log.apply(console, args);
}
};
Then utilize consoleLog exclusively in your application code.
Benefit of this indirection:
It's safer. You never monkey-patch the original console.log at all.
It's more future-proof. If you switch from console.log to e.g. a 3rd-party logging framework later, you don't have to adjust all your logging code.
However, if you are intentionally configuring code beyond your control (3rd-party) that uses console.log, this of course will not work for that case.
With this approach, for unit testing, spy on console.log (which was never modified) as recommended in the answer from estus.
It's generally not a good practice to monkey-patch global APIs. And it's better to expose original function just in case, at least for testing purposes.
It would be easier to test it if it were more flexible, e.g. patched code could be controlled with environment variables, in case there's a need to fall back to original behaviour:
console._logOriginal = console.log;
console.log = (...args) => {
if (
!process.env.NO_HMR_SPAM ||
(args.length === 0 || typeof args[0] !== 'string' || !args[0].includes('[HMR]'))
) {
console._logOriginal(...args);
}
};
In this case console._logOriginal can be spied.
Otherwise original console.log should be backed up before this module is evaluated, it shouldn't be imported before that:
const consoleLogOriginal = console.log;
it('...', async () => {
const consoleLogSpy = jest.spyOn(console, 'log');
await import('moduleThatManglesConsole');
console.log('[HMR]');
expect(consoleLogSpy).not.toHaveBeenCalled();
console.log('');
expect(consoleLogSpy).toHaveBeenCalledWith('');
})
afterEach(() => {
console.log = consoleLogOriginal;
});

Prevent React dev tools from changing props/state

Is there a way to prevent any prop/state change from front-end on production?
I tried following but it completely disables the dev tools:
if (typeof window.__REACT_DEVTOOLS_GLOBAL_HOOK__ === 'object') {
for (let [ key, value ] of Object.entries(
window.__REACT_DEVTOOLS_GLOBAL_HOOK__
)) {
window.__REACT_DEVTOOLS_GLOBAL_HOOK__[key] =
typeof value === 'function' ? () => {} : null;
}
}
I use the following bit of code in my Meteor application that uses React 16.3 as the UI library.
The window.__ALLOW_REACT_DEVTOOLS__ is just a flag I set in the SSR html sent from the server because this line of code needs to preclude any React code, and I need it before process.env is available in the browser. On the server I set that value to false in production.
<script>
if (
!window.__ALLOW_REACT_DEVTOOLS__ &&
window.__REACT_DEVTOOLS_GLOBAL_HOOK__ &&
typeof window.__REACT_DEVTOOLS_GLOBAL_HOOK__ === "object"
) {
for (let [key, value] of Object.entries(window.__REACT_DEVTOOLS_GLOBAL_HOOK__)) {
window.__REACT_DEVTOOLS_GLOBAL_HOOK__[key] = typeof value == "function" ? ()=>{} : null;
}
}
delete window.__ALLOW_REACT_DEVTOOLS__;
</script>
The key to making this work is that it is loaded BEFORE React.
This will completely disable React-Devtools. When you click on the devtools tab it will just say 'Looking for React...'.
Okay, found a way to keep even that function from getting injected/involved.
I just changed the disabler code to this:
// disable react-dev-tools for this project
if (typeof window.__REACT_DEVTOOLS_GLOBAL_HOOK__ === "object") {
for (let [key, value] of Object.entries(window.__REACT_DEVTOOLS_GLOBAL_HOOK__)) {
window.__REACT_DEVTOOLS_GLOBAL_HOOK__[key] = typeof value == "function" ? ()=>{} : null;
}
}

Check if URL() suported

How to check if the class URL() is supported in the current browser?
Based on the docs it's not supported in IE
I want to use it to get a domain out of a string like that:
var text = ...
var domain = new URL(text).host;
You could do a feature check with
if ("URL" in window)
However this won't validate whether the functionality is correct. you might want to consider adding a polyfill.
Note that IE/Edge seem to really make built in constructors as objects, meaning typeof Ctor === "object" is true in those browsers. So if they add support in Edge for it, the checks for "function" will be invalid.
You can't do this with complete reliability. You could come close by testing if URL exists and is a function:
if (typeof URL !== "function") {
// It is not supported
}
You could then perform further tests to see how much it looks like a duck:
function URL_is_supported() {
if (typeof URL !== "function") {
return false;
}
// Beware: You're calling the function here, so it it isn't the expected URL function it might have undesired side effects
var url = new URL("http://example.com");
if (url.hostname !== "example.com") {
return false;
}
// and whatever other tests you wanted to do before you're convinced
return true;
}
to check if anything is supported on a root level (window) just try to access it on a condition level. E.G.
(window.URL) OR JUST (typeof URL === "function")
var a = window.URL ? window.URL(text).host : ....
also remembering that the fact of window has a "URL" property doesn't mean that it is a class/function and that it is what you expect
so the best approach would be check using the typeof version which at least guarantee that it is a function
The closest you can get to check if URL is truly supported is checking its prototype and static functions
function isURLSupported(){
if(typeof window.URL!=="function" || typeof URL.createObjectURL !== "function" || typeof URL.revokeObjectURL !== "function"){
return false;
}
var oURLprototype= ["host","hostname","href","origin","password","pathname","port","protocol","search","searchParams","username"];
for(var i=0;i<oURLprototype.length;i++){
if(URL.prototype.hasOwnProperty(oURLprototype[i])===undefined){
return false;
}
}
return true;
}
For those who will support implementations that have classes as type Object not Function
--Is function credit to https://stackoverflow.com/a/7356528/835753
function isFunction(functionToCheck) {
var getType = {};
return functionToCheck && getType.toString.call(functionToCheck) === '[object Function]';
}
function isURLSupported(){
if(!isFunction(window.URL) || !isFunction(URL.createObjectURL) || !isFunction(URL.revokeObjectURL)){
return false;
}
var oURLprototype= ["host","hostname","href","origin","password","pathname","port","protocol","search","searchParams","username"];
for(var i=0;i<oURLprototype.length;i++){
if(URL.prototype.hasOwnProperty(oURLprototype[i])===undefined){
return false;
}
}
return true;
}

javascript load external file and continue processing

So I'm trying to avoid loading certain scripts until the user needs them but I keep ending up in the pattern of using an if...else and putting the call to the continue code in both places. In the code below you can see the two calls to the continueProcessing() method. Is there a better way of doing this?
if (typeof sessionList === "undefined" || typeof sessionList != "function") {
$.getScript('resources/sessionList.js', function() {
continueProcessing();
});
} else {
continueProcessing();
}
function continueProcessing() {
// do stuff
}
I haven't used getScript, but have faced a similar challenge with loading html templates. I've been using the deferred / promise approach. It would look like this for your case:
var jqXHR = {};
if (typeof sessionList === "undefined" || typeof sessionList != "function") {
jqXHR = $.getScript('resources/sessionList.js');
}
$.when(jqXHR).then(continueProcessing());
In the case where the script already exists, the jqXHR var will not be a deferred, so the "then" is executed immediately.
This is still a bit of code to type, but at least "continueProcessing" only appears once.
This looks like a good way of doing it to me.
So I played with the $.Deferred pattern/code and I came up with this. It's not as terse but I think it's a cleaner way of doing it. Looks like I have a lot of code to refactor...
var dfd = $.Deferred();
if ( typeof sessionList === "undefined" || typeof sessionList != "function" ) {
$.getScript('resources/sessionList.js', function(){
dfd.resolve();
});
}
dfd.done(function() {
continueProcessing();
});

console.log.apply not working in IE9

Looks like I've re-invented the wheel, but somehow this isn't working in Internet Explorer 9, but does in IE6.
function debug()
if(!window.console) {
window.console = { log: function() { /* do something */ } };
}
console.log.apply(console, arguments);
}
Related:
Apply() question for javascript
F12 Debugger tells me that this "object" (console.log) does not support method 'apply'.
Is it not even recognized as a function?
Any other pointers or ideas?
The second part of an answer I gave recently answers this question too. I don't consider this a duplicate of that one so, for convenience, I'll paste it here:
The console object is not part of any standard and is an extension to the Document Object Model. Like other DOM objects, it is considered a host object and is not required to inherit from Object, nor its methods from Function, like native ECMAScript functions and objects do. This is the reason apply and call are undefined on those methods. In IE 9, most DOM objects were improved to inherit from native ECMAScript types. As the developer tools are considered an extension to IE (albeit, a built-in extension), they clearly didn't receive the same improvements as the rest of the DOM.
For what it's worth, you can still use some Function.prototype methods on console methods with a little bind() magic:
var log = Function.prototype.bind.call(console.log, console);
log.apply(console, ["this", "is", "a", "test"]);
//-> "thisisatest"
So you could fix up all the console methods for IE 9 in the same manner:
if (Function.prototype.bind && window.console && typeof console.log == "object"){
[
"log","info","warn","error","assert","dir","clear","profile","profileEnd"
].forEach(function (method) {
console[method] = this.bind(console[method], console);
}, Function.prototype.call);
}
This replaces the "host" functions with native functions that call the "host" functions. You can get it working in Internet Explorer 8 by including the compatibility implementations for Function.prototype.bind and Array.prototype.forEach in your code, or rewriting the above snippet to incorporate the techniques used by those methods.
See also
console.log typeof is "object" instead of "function" - Microsoft Connect (Live account required)
There is also Paul Irish's way of doing it. It is simpler than some of the answers above, but makes log always output an array (even if only one argument was passed in):
// usage: log('inside coolFunc',this,arguments);
// http://paulirish.com/2009/log-a-lightweight-wrapper-for-consolelog/
window.log = function(){
log.history = log.history || []; // store logs to an array for reference
log.history.push(arguments);
if(this.console){
console.log( Array.prototype.slice.call(arguments) );
}
};
Several of IE's host object functions aren't really JavaScript functions and so don't have apply or call. (alert, for example.)
So you'll have to do it the hard way:
function debug()
var index;
if(!window.console) {
window.console = { log: function() { /* do something */ } };
}
for (index = 0; index < arguments.length; ++index) {
console.log(arguments[index]);
}
}
I came across the same IE trouble and made a routine for it.
It is not as fancy as all the above implementations, but it works in ALL modern browsers.
I tested it with Firefox (Firebug), IE 7,8,9 Chrome and Opera.
It makes use of the evil EVAL, but you will only want to debug in development.
Afterwards you will replace the code with debug = function () {};
So here it is.
Regards, Hans
(function(ns) {
var msgs = [];
// IE compatiblity
function argtoarr (args,from) {
var a = [];
for (var i = from || 0; i<args.length; i++) a.push(args[i]);
return a;
}
function log(arg) {
var params = "", format = "", type , output,
types = {
"number" : "%d",
"object" : "{%o}",
"array" : "[%o]"
};
for (var i=0; i<arg.length; i++) {
params += (params ? "," : "")+"arg["+i+"]";
type = types[toType(arg[i])] || "%s";
if (type === "%d" && parseFloat(arg[i]) == parseInt(arg[i], 10)) type = "%f";
format += (format ? "," : "")+type;
}
// opera does not support string format, so leave it out
output = "console.log("+(window.opera ? "" : "'%f',".replace("%f",format))+"%p);".replace("%p",params);
eval(output);
}
ns.debug = function () {
msgs.push(argtoarr(arguments));
if (console !== undefined) while (msgs.length>0) log(msgs.shift());
}
})(window);
Oops forgot my toType function, here it is.
function toType(obj) {
if (obj === undefined) return "undefined";
if (obj === null) return "null";
var m = obj.constructor;
if (!m) return "window";
m = m.toString().match(/(?:function|\[object)\s*([a-z|A-Z|0-9|_|#]*)/);
return m[1].toLowerCase();
}
Ok, it works when you write it this way:
function debug()
if(!window.console) {
window.console = {};
console.log = function() { /* do something */ };
}
console.log.apply(console, arguments);
}
Odd behaviour... but if you write it this way 'console.log' gets recognized as a function.
The reason I came to this question was that I as trying to 'spicy' the console.log function for a specific module, so I'd have more localized and insightful debug info by playing a bit with the arguments, IE 9 broke it.
#Andy E answer is great and helped me with lots of insight about apply. I just don't take the same approach to support IE9, so my solution is running the console only on "modern browsers" (being that modern means whatever browsers that behave the way I expect =)
var C = function() {
var args = Array.prototype.slice.call(arguments);
var console = window.console;
args[0] = "Module X: "+args[0];
if( typeof console == 'object' && console.log && console.log.apply ){
console.log.apply(console, args);
}
};
Try:
function log(type) {
if (typeof console !== 'undefined' && typeof console.log !== 'undefined' &&
console[type] && Function.prototype.bind) {
var log = Function.prototype.bind.call(console[type], console);
log.apply(console, Array.prototype.slice.call(arguments, 1));
}
}
log('info', 'test', 'pass');
log('error', 'test', 'fail');
Works for log, debug, info, warn, error, group or groupEnd.

Categories

Resources