Opened 10 years ago

Closed 9 years ago

#10699 closed defect (wontfix)

console Problem in IE8

Reported by: Avachan Owned by: anonymous
Priority: high Milestone: tbd
Component: Core Version: 1.4.0
Keywords: Cc:
Blocked By: Blocking:

Description

Hi, Since Version 1.4.0 I have a Problem with the console div under IE8. In IE7 and FF3.6 (with firebug) it works correct, but in IE8 the console div would not be shown under the written Application.

I have test to set some Variables in the djConfig like the debugAtAllCosts Flag, but it didn't work after all.

The IE8 is often implemented in other Software so I can't use the IE8 internal JavaScript? debugging Services. So I don't know if they would help and replace the console window.

Sincerly, Ava-chan

Attachments (1)

test.php (1.0 KB) - added by Avachan 10 years ago.
Testfile to set dojoVersions for tests of console div

Download all attachments as: .zip

Change History (10)

Changed 10 years ago by Avachan

Attachment: test.php added

Testfile to set dojoVersions for tests of console div

comment:1 Changed 10 years ago by bill

Component: GeneralCore
Milestone: 1.4.2tbd
Owner: changed from anonymous to Mike Wilcox
Priority: highnormal

You must be talking about the firebug lite console. That was removed on purpose in favor of the IE8 built-in console. (Too bad you can't use it.) See #9744.

Assigning to Mike but probably we don't want to change the current behavior.

You can get the old behavior by hacking firebug.js.

comment:2 Changed 10 years ago by Mike Wilcox

Resolution: wontfix
Status: newclosed

From: http://mail.dojotoolkit.org/pipermail/dojo-interest/2009-December/041482.html

The detection for it had gotten too complicated, what with IE8, IE7 with/wo a console (and the fact that it's not there until the dom loads) and Safari's Introspector.

I had something like forceFirebugLite I think - but then I got complaints that it was not clearly defined or something.

On top of this, there was a big discussion on whether we would have a custom debug space in dojox and support that, along with extension (this has not taken off).

But mainly, the FBL detection in 1.3 was poor and it threw occasional errors and would open FBL when you didn't want it to.

I just now tried doing this:

if(

(dojo.config.forceFirebugLite)
(

!dojo.isFF && Firefox has Firebug

(!dojo.isChrome (!dojo.isSafari
dojo.isChrome < 3) &&
dojo.isSafari < 4) && Safari 4 has a console

!isNewIE && Has the new IE console !window.firebug && Testing for mozilla firebug lite (typeof console != "undefined" && !console.firebug) && A console

that is not firebug's

!dojo.config.useCustomLogger && Allow custom loggers !dojo.isAIR isDebug triggers AIRInsector, not Firebug

) ){

This works, and I recommend that you hack your local copy to do that. But this is not ideal to commit, because if you have Firebug open, FBL will try to overwrite console and throw a setter error. So it would require even *more* detection.

So I'm afraid this will have to be a "can't fix" for now. Someone is working on a really nice replacement for FBL (or maybe a addon custom logger, not sure) and hopefully he will commit it soon. That should be a little more versatile.

comment:3 Changed 10 years ago by Avachan

Oh ... ok : ) Thx for the explanation. I replaced the 1_4_1 firebug.js through the 1_3_2 firebug.js and be happy to have a debugging tool : ) It's a big problem to debug JS Code in embedded IE Systems. So I like this feature.

The discussion reads very nice. And thx for the code. I hope the new debug console will come soon and remain in anticipation.

Sincerly, Ava-chan

comment:4 in reply to:  2 Changed 10 years ago by davidmark

Resolution: wontfix
Status: closedreopened

Replying to mwilcox:

From: http://mail.dojotoolkit.org/pipermail/dojo-interest/2009-December/041482.html

The detection for it had gotten too complicated, what with IE8, IE7 with/wo a console (and the fact that it's not there until the dom loads) and Safari's Introspector.

That's what happens with non-logic like browser sniffing.

I had something like forceFirebugLite I think - but then I got complaints that it was not clearly defined or something.

An explicit flag to determine whether that faux console is included is a good idea.

On top of this, there was a big discussion on whether we would have a custom debug space in dojox and support that, along with extension (this has not taken off).

But mainly, the FBL detection in 1.3 was poor and it threw occasional errors and would open FBL when you didn't want it to.

Do you mean the detection of the browser console? That's what determines whether FBL is included (and the logic is wrong).

I just now tried doing this:

if(

(dojo.config.forceFirebugLite)
(

!dojo.isFF && Firefox has Firebug

(!dojo.isChrome (!dojo.isSafari
dojo.isChrome < 3) &&
dojo.isSafari < 4) && Safari 4 has a console

!isNewIE && Has the new IE console !window.firebug && Testing for mozilla firebug lite (typeof console != "undefined" && !console.firebug) && A console

that is not firebug's

!dojo.config.useCustomLogger && Allow custom loggers !dojo.isAIR isDebug triggers AIRInsector, not Firebug

) ){

This works, and I recommend that you hack your local copy to do that.

No. That does _not_ work. That is just a temporary band-aid that illustrates what it would do if it actually worked. Look at the code. Is the idea to change it every time a new browser is released? What about browsers you never heard of? It makes no sense to ask people to constantly update an ostensibly cross-browser script.

But this is not ideal to commit, because if you have Firebug open, FBL will try to overwrite console and throw a setter error. So it would require even *more* detection.

That's FBL's problem. Why are you using it if it is that stupid?

So I'm afraid this will have to be a "can't fix" for now. Someone is working on a really nice replacement for FBL (or maybe a addon custom logger, not sure) and hopefully he will commit it soon. That should be a little more versatile.

Hopefully it will be competently done (e.g. no browser sniffs, no stepping on the browser console). In the meantime, this can be fixed as the FBL source is in Dojo.

comment:5 Changed 10 years ago by davidmark

Owner: changed from Mike Wilcox to davidmark
Status: reopenednew

This FBL thing is a colossal piece of garbage. Read it and weep:-

	var isNewIE = (/Trident/.test(window.navigator.userAgent));
	if(isNewIE){
		// Fixing IE's console
		// IE doesn't insert space between arguments. How annoying.
		var calls = ["log", "info", "debug", "warn", "error"];
		for(var i=0;i<calls.length;i++){
			var m = calls[i];
			var n = "_"+calls[i]
			console[n] = console[m];
		console[m] = (function(){
				var type = n;
				return function(){
					console[type](Array.prototype.slice.call(arguments).join(" "));
				}
			})();
		}
		// clear the console on load. This is more than a convenience - too many logs crashes it.
		// If closed it throws an error
		try{ console.clear(); }catch(e){}
	}
	
	if(
		!dojo.isFF &&								// Firefox has Firebug
		(!dojo.isChrome || dojo.isChrome < 3) &&
		(!dojo.isSafari || dojo.isSafari < 4) &&	// Safari 4 has a console
		!isNewIE &&									// Has the new IE console
		!window.firebug &&							// Testing for mozilla firebug lite 
		!dojo.config.useCustomLogger &&				// Allow custom loggers
		!dojo.isAIR									// isDebug triggers AIRInsector, not Firebug
	){	

And the idea of replacing window.console is ludicrous. You should have wrappers for log, warn, etc. They can echo to the built-in console, faux consoles or whatever. That's how I did it in My Library and IE8 caused me no grief whatsoever (on anything really). It's all in the design, but unfortunately you are hemmed in by a bad decision made a long time ago. Compounding it with more browser sniffing is not the answer.

Need to lose that uber-confusing debugAtAllCosts flag as well.

comment:6 Changed 10 years ago by davidmark

ISTM that the browser sniffing can be reduced to something like:-

if (!window.console
!window.console.log) {

That's what you want to know (not whether it is IE8 or AIR or Safari 3 or whatever). And who cares if it is not Firebug? A built-in console is much preferable to one that pollutes the DOM (and uses tons of browser sniffing to boot). As IE8 may not populate that object immediately (?), you may well get the DOM pollution whether you need it or not. So...

For those who want (or don't want) the FBL thing at all costs, you need to use an explicit djconfig flag (e.g. useFireBugLite). Let the user decide whether they want the thing in the current test page. Trying to be too clever with all of this sniffing results in code that must be revisited every few months (and likely every few days in the future). There's already _way_ too much of this stuff (and too few contributors) to keep up. Seems every ticket is related to one sniff or another (and the sniff count goes up each time as more workarounds are added). All very predictable (and easily fixed as in the featuredetection branch).

Where is this discussion about such a strategy being "not clearly defined?" That doesn't make any sense to me (which isn't surprising given the quality of the typical "argument" posted here). :) Trust that an explicit flag is the only sane solution (at least from where the users sit).

comment:7 Changed 10 years ago by davidmark

Typo (or missing code block fouled it up)

if (!window.console || !window.console.log) {

comment:8 Changed 9 years ago by dante

Owner: changed from davidmark to anonymous

comment:9 Changed 9 years ago by Mike Wilcox

Resolution: wontfix
Status: newclosed

Did David open this just to complain about browser sniffing? This is a deprecated module and is getting the job done in its last days. Don't touch it if ain't broke.

Note: See TracTickets for help on using tickets.