Handling script errors from three different perspectives

Handling script errors from three different perspectives | Microsoft Share Point

Handling script errors from three different perspectives | Microsoft Share Point — Thu, 09 Apr 2009 02:27:32 GMT

PingBack from http://microsoft-sharepoint.simplynetdev.com/handling-script-errors-from-three-different-perspectives/

re: Handling script errors from three different perspectives

gabe — Thu, 09 Apr 2009 04:20:11 GMT

it seems when you have a lot of sites listed in restrited sites it slows ie8 download

http://www.safer-networking.org/en/news/2009-03-25.html

re: Handling script errors from three different perspectives

8675309 — Thu, 09 Apr 2009 06:20:20 GMT

i just noticed today that this blog is finally script error free thats good!

re: Handling script errors from three different perspectives

Brian — Thu, 09 Apr 2009 06:45:21 GMT

exactly what i was looking for.

thanks.

re: Handling script errors from three different perspectives

FremyCompany — Thu, 09 Apr 2009 13:04:05 GMT

Now, it would be even better if we could have the Debug window embeded in the Browser window when debugging :)

Second thing, when we perform a search in the 'Script tag' and that a HTML document is loaded, the results that are in a TextNode element (not in a <SCRIPT>, <STYLE> or attribute) should not be shown. If no match is found in the document, a message should say it, rather than closing the search silently.

Third thing : when we're debugging, it should be great to have a log of all 'catched' errors via a try block. Sometimes, the error is catched but the program don't work either, and it's very difficult to see where the error is catched.

Also, it's not a Script problem, but when we try to select an element with 'Find element by click' and that the currently selected element is not in the loaded DOM of the DevTools, it should automatically update itself (but not more than 15 or 25 updates per time we click 'Find element' because if we're on a zone where innerHTML is setted every 150 ms, we'll turn into an infinite 'reload' loop)

re: Handling script errors from three different perspectives

Eion Robb — Thu, 09 Apr 2009 14:10:00 GMT

Faaaaantastic! Debugging stuff in IE6 and IE7 was always hard, but I've finally been able to fix years-old IE bugs with IE8's debugging instead of hacky workarounds :)

re: Handling script errors from three different perspectives

PM — Thu, 09 Apr 2009 15:20:24 GMT

and how to debug a IE8 compatibility issue if there are no error messages of any type (no html errors : xhtml valid, no js errors) ?

for example : http://www.preference-formations.fr/index.php?id=107, the ajax autocomplete (try with btsa) works well under IE 7 / FF / opera / chrome / safari and breaks under IE 8 : the links (A tag)seem to be interpreted by IE 8 not as links (no pointer change, no css style hover). With the compatibily mode it's OK : so what's going wrong ? I think it's something relative to js events and callback functions but no js errors are returned by IE8... And with the inspect tool how to inspect a dynamic div (can access to source code with firebug) ?

re: Handling script errors from three different perspectives

Olivier — Thu, 09 Apr 2009 15:32:44 GMT

@FremyCompany : what do you mean by embedding the debug window in the browser ? If you want, you can pin the window at the bottom of the browser by clicking the button below the minimize/maximize/close buttons of the debug window.

BTW : I think it would have been better if this button had a pin icon.

IE8 and your Rich Web

No1 Microsoft Fan — Thu, 09 Apr 2009 15:47:35 GMT

Using IE8? Issues ? Something broken? Truth is, on Vista I stopped using IE8 in the middle of the beta

re: Handling script errors from three different perspectives

FremyCompany — Thu, 09 Apr 2009 15:57:59 GMT

@Olivier : Yes, you can 'pin' the window. But if you start debugging JScript (Script > Start Debbgging), the window is automatically unpinned.

The reason have already been explained by the IETeam during a IE Team chat (I don't remind the date, however) : While a break point is encountered, the JScript is interrupted. The problem is that the browser window runs in the same thread as the JScript, so the window freeze. You can't click on the "Continue" button of the developpers tools or do anything because all is freezed.

To fix this problem, they have forced 'unpinned' mode while you're debugging JScript.

re: Handling script errors from three different perspectives

Buzz — Thu, 09 Apr 2009 16:23:22 GMT

Its an improvement, but still gives false readings.

The following line was in a ajax model popup, which caused a error something like object not defined, highlighting part of the viewstate field. The real error was the "hide()" javascript function did not exist (firefox correctly identified this).

"<asp:ImageButton ID="ibSearch" ImageUrl="~/images/searchbox/searchright.gif" CssClass="searchbutton" runat="server" OnClientClick="hide()" CausesValidation="false" EnableViewState="false" />"

re: Handling script errors from three different perspectives

rc — Thu, 09 Apr 2009 16:31:22 GMT

By the way, how to see CSS declarations that browser applies by default?

In Developer Toolbar for IE 6 and 7 I used to check "Show default style values" in bottom-right corner, and it showed me all CSS properties for current element with current applied values, marked default browser styles with gray.

From this I knew, for example, that 'h1' has font-size: 24pt by default, and that body has margin: 10px 15px by default.

But I see nothing similar in Developer Tools for IE 8. It only shows styles from author's style sheet, not from browser's settings. It is rather inconvinient.

re: Handling script errors from three different perspectives

TheUndeadable — Thu, 09 Apr 2009 17:14:11 GMT

There is a quite ugly bug in the german translation:

http://www.depon.net/temp/1144139.png

re: Handling script errors from three different perspectives

steve — Thu, 09 Apr 2009 17:19:24 GMT

Congratulations Microsoft! It only took you until version 8 (EIGHT) of Internet Explorer to have your JavaScript error dialog report the CORRECT File/Line Number of the error!

So glad we gave you the "Freedom to Innovate" such a remarkable feature!

I wonder when the other browsers will copy this cool idea?... oh wait, they did it years ago - since day one!

The other browser's seem to have this philosophy of only shipping a quality product where if the feature is known to be broken, they don't ship the feature.

I can't believe it has been a DECADE to fix this bug!

About !@^$!@#$!%@ing time!

re: Handling script errors from three different perspectives

steve — Thu, 09 Apr 2009 17:28:47 GMT

oh, nice! the German version is useless!

More issues:

1.) Oh, and the one major, important button you forgot on the JavaScript console is the:

[ C L E A R ]

Clear button! Without it you can't clear any old errors before AJAX/DOM events fire more errors.

2.) There is NO link to the file that threw the error! This was available since the Netscape 4.x days at least!

re: Handling script errors from three different perspectives

fr — Thu, 09 Apr 2009 17:47:24 GMT

There still needs to be a snippet from the actual line where the error occured in the error dialog to aid you in finding the problem, it would be much easier than using the line number/char number combination.

re: Handling script errors from three different perspectives

dom — Thu, 09 Apr 2009 17:54:23 GMT

I'd like to send feedback on the "Webpage Error" dialog.

Why in 2009 on Windows XP and Windows Vista (and Windows 7?) does this dialog and many others STILL have buttons and controls rendered in the ugly styles from 1995 (14 YEARS AGO PEOPLE!)

Not only is it horribly ugly but it makes IE look like neglected software that has not been kept up and can't keep up with the pace of modern software design.

Task a UI person RIGHT NOW! to get on this and fix every dialog in IE - its a shame that IE has the biggest market share yet is the ugliest browser available.

re: Handling script errors from three different perspectives

JossB — Thu, 09 Apr 2009 18:31:23 GMT

As previously mentioned, it would be good to have the full line of code where the error occured displayed. The stack trace would also be a huge plus. Line and char is just sometimes confusing when dealing with ASP / PHP pages because javascript might be generated dynamically. Or a way to see the full javascript as seen by the browser would be awesome.

re: Handling script errors from three different perspectives

EricLaw [MSFT] — Thu, 09 Apr 2009 19:23:15 GMT

@gabe: Yes, putting thousands of sites in the Restricted Zone will slow IE startup performance. It doesn't actually affect "download" performance.

@JossB: The script debugger will show the JavaScript as seen by the browser.

@steve: I'm not sure what you mean when you say the "german version is useless."

@TheUndeadable: Is the problem that the controls are messed up, or something else? Do you ALWAYS see this problem, or do you only see it after you use the dev toolbar to manually force the current document into strict mode?

@Buzz: Please provide a URL that reproduces the problem?

@PM: Simply click the "Find element by click" icon (the mouse pointer icon in dev tools) to find see the source of the element and determine if there is something overlapping it preventing the link from activating.

re: Handling script errors from three different perspectives

ph — Thu, 09 Apr 2009 19:24:36 GMT

please fix the error text in external debugger dialog (the last screenshot, above).

The line number is wrong - it should be '5', not '4'. and the filename/code should be shown, also.

re: Handling script errors from three different perspectives

John Hrvatin [MSFT] — Thu, 09 Apr 2009 19:27:00 GMT

@steve:

the quickest way to clear the console is right-clicking in the console and choosing "clear console"

re: Handling script errors from three different perspectives

TheUndeadable — Thu, 09 Apr 2009 19:35:07 GMT

@EricLaw:

Good point. Only after changing the rendering mode.

re: Handling script errors from three different perspectives

EricLaw [MSFT] — Thu, 09 Apr 2009 19:35:27 GMT

@PM: It looks like you're using an outdated version of the scriptaculous library.

The current version is 1.8.2 which you can get here: http://script.aculo.us/; it may fix the problem.

The specific problem with the site can be fixed by editing /typo3/contrib/scriptaculous/controls.js

to comment out the following two lines for IE8:

this.iefix = $(this.update.id+'_iefix');

if(this.iefix) setTimeout(this.fixIEOverlapping.bind(this), 50);

Performance issue

Nick — Thu, 09 Apr 2009 21:13:15 GMT

As a full-time web developer (I've been working as a developer for agencies in Seattle since 1996), I'm thrilled to see IE get some of the same features that Firebug offers Firefox.

I'm unhappy about the sharing of keyboard shortcuts between the developer tools window and IE 8. If I dock the developer tools, then hit Ctrl-T to open a new tab, I'm told to "Please select an element using the DOM Explorer."

Speaking of Ctrl-T -- Why does opening a new tab (Ctrl-T) in IE 8 take 2 seconds on my system? This same operation is instantaneous using Firefox 3. This contributes hugely to a general feeling of "slowness" while using IE 8. I'd like to find out if I can change a setting within IE 8 to eliminate this 2 second delay. The title of the new tab says "Connecting..." during this delay before the title then changes to "New Tab" and focus switches to the new tab.

re: Handling script errors from three different perspectives

EricLaw [MSFT] — Thu, 09 Apr 2009 22:09:53 GMT

@Nick: Slowness in creating new tabs is almost always caused by poorly performing addons. The Java SSV Helper in particular is known to be one issue with addons.

The first step is to try in no-addons mode to see if this helps: www.enhanceie.com/ie/troubleshoot.asp#crash

If so, then use the Manage Addons tool to look at the load time for each addon and disable unneeded addons.

Running with a small set of addons (including a few BHOs) new tabs open on my system in under 200ms.

re: Handling script errors from three different perspectives

Shedy — Thu, 09 Apr 2009 23:21:11 GMT

EricLaw [MSFT],

Well.. Tabs should open fast even if you have many or buggy addons..

Firefox handle this well.

re: Handling script errors from three different perspectives

Dan — Thu, 09 Apr 2009 23:28:50 GMT

Shedy, no, Firefox doesn't handle this any better than IE does. If you have slow Firefox addons in Firefox, you have a slow Firefox.

http://labnol.blogspot.com/2007/09/firefox-runs-slow-speed-memory-fast.html

The difference here is that Firefox users tend to more closely look at what addons they have, and if they install slow ones, they uninstall them.

re: Handling script errors from three different perspectives

Travis Leithead [MSFT] — Thu, 09 Apr 2009 23:56:33 GMT

@rc: The feature you want was moved into the "Attributes" button under the HTML tab. Click the checkbox at the bottom that says "Show Read-Only Properties" to see all the CSS properties...

re: Handling script errors from three different perspectives

JossB — Fri, 10 Apr 2009 03:25:54 GMT

@EricLaw [MSFT] : what I ment actually is eventually having the javascript as seen by the browser inside the script error dialog in order to fully understand what the error report means. Having the line of code + stack trace would also help much since this dialog box appears when the script debugger is not activated. When debugging AJAX applications, things can become a real pain to debug, and bugs may only appear under certain circumstances. The more information we get from the client, the easier it is to debug afterward. One more thing : a possibility to make a "dump" of the script code / variables would be a real plus from this window as client would be able to send it for debugging. Maybe in the next version ?

re: Handling script errors from three different perspectives

hAl — Fri, 10 Apr 2009 09:23:12 GMT

That the slow Research addon has not been removed/updated is a disgrace.

It is even produced by MS them selves.

Also I still have several of the most common addons which do not show load time like the Java SVV helper plugin and shockwave flash.

How can that be ?

re: Handling script errors from three different perspectives

Klimax — Fri, 10 Apr 2009 10:07:04 GMT

@george: What JS console? The one in Developer tools or the one from Sun?First has such command second had it as well.

Second:YOu can disable any and all plugins.Removal for majority is disabled as it is being done in Add/remove(Programs and features) dialog under control panel.

But usually disable is enough as it eliminates any call what so ever to it,so its functionality is deactivated.

Thos MS plugins you mentioned where older ones and where updated,since usually it was bug in them causing slow init.

Why no list?There are tons of variables in play here,various interactions and one some machines one plugin will slow it ,while on the other not.

And some of them were in reports/known problems),but not in blog but in connect site.

(Which is sadly down)-(Maybe in comments)

re: Handling script errors from three different perspectives

rc — Fri, 10 Apr 2009 11:49:33 GMT

@Travis Leithead [MSFT]

No, it doesn't show CSS properties! It shows many read-only DHTML attributes such as offsetHeight, innerHTML and nodeType, but none of CSS - no margin, font-family, text-align etc.

This tool allows to add new CSS properties and to assign new values to them, but doesn't show values that already exist. :-(

re: Handling script errors from three different perspectives

Travis Leithead [MSFT] — Fri, 10 Apr 2009 18:43:02 GMT

@rc: yes, after looking at this again, you are correct. The data _is_ available, but it's not trivial to get it (sorry about that)! Basically, you would need to use the Console to find the element you want to inspect, and then for..in the properties of the element's currentStyle object. I think that's essentially what the IE7 dev toolbar provided.

re: Handling script errors from three different perspectives

Travis Leithead [MSFT] — Fri, 10 Apr 2009 18:43:17 GMT

re: Handling script errors from three different perspectives

James — Wed, 15 Apr 2009 05:42:24 GMT

Thank you for this! It will make a huge difference in development. Something I did not see, perhaps I missed it, was the ability to view ajax requests, I think most of us are now familiar with firebug and its excellent UI and features. A way of presenting xmlhttprequests similar to that would be a great addition. Other than that IE is fast becomming a great browser for the masses again, so congrats on this.

Finally, what about plugins, such things as htmlvalidator, live http headers on ff are extremely useful.

re: Handling script errors from three different perspectives

EricLaw [MSFT] — Wed, 15 Apr 2009 18:29:37 GMT

@James: If you haven't taken a look at Fiddler yet (www.fiddler2.com) I encourage you to try it. It works with IE, Firefox, and all other browsers, and is significantly more powerful than the header-viewing-only plugins. You can not only view, but modify, archive, and compare all HTTP/HTTPS traffic.

(FWIW: IE8's developer tools already integrate a HTML validator.)