Javascript Debugging With IE7

Question

Hello,

I have ran across an issue debugging an ASP.Net page after installing IE7 on my development machine and I have not been able to find a solution. I am using Visual Studio 2003 and I am no longer able to access the rendered source (including embedded javascript which is emitted in the code behind) using Debug -> Windows ->Running Documents -> Page.aspx  When I click on the running page in the Running Documents, all that displays is the source page and not the page that is running in the browser. Doing these same steps in IE6 worked fine. Also, note that the debugger statement does break but only shows the source page (not the running page) in Visual Studio and places the break at the end of the </html> tag. Therefore, I am unable to see dynamic javascript which is emitted to the page in the code behind. In addition, I have made sure that Disable script debugging  is unchecked in the Advanced Settings of IE7.

Thanks,

Dustin

Answer 1

Hi Dustin,

We are aware of this issue and currently working on a fix. Unfortunately, I can't give you a date of when this will be available for VS2003. One way to work around this issue is to separate the client javascript in a .js include file instead of having it embedded in a <script> block directly in the .aspx page. I know this is not the most convenient solution but hope it helps as a temporary solution.

Monica

 

Answer 2

Is this a 'fix' to VS2003 or IE7?  Which one is 'broken'?

Another 'temporary solution' is to uninstall IE7 until it is out of beta.

 

Answer 3

Hi Dustin,

There is a change in IE7 that caused this issue in Visual Studio. IE7 will not change so waiting for the RTM will not solve the problem. The issue will be addressed in VS.

Thanks,

Monica Boris [msft]

Answer 4

Hi,

I just have to deplore this solution.

" I know this is not the most convenient solution but hope it helps as a temporary solution."

It seem to be the ultimate sentence when talking about web development on windows.

 

Answer 5

This really needs an expedited solution.

Changing code in order to debug it takes us back to the 70's.

And no firewall administrator is going to like allowing ".js" files to be downloaded.

A solution is to detach all in Visual Studio. Then open a new instance of a debugger and attach to the window to be debugged.

The simplest solution is to uninstall IE7.  I'm debating whether to use that ultimate solution.

Answer 6

This also breaks .htc files and seperating the javascript out these is a nightmare.

Answer 7

This situation absolutely sucks.... IE 7 has been released to the general public now.

I would have thought that the majority of new signups would have been developers and that this should have been made aware to developers via the simple home startup page.  Microsoft never seem to admit to issues straight away and its taken me the best part of 4 hours searching this issue.

IE7 will be removed from my development machine.  Not only does it not work with VS2005 there seems to be a few sites out there that lock IE7 into 100% CPU usage.

Back to firefox 2 i think

Answer 8

Yes this truly sucks . Considering how long the VS2003 SP took to come out I'm not holding my breath for a fix :( As for reverting back to IE6 (uninstalling IE7), have spent most of today regretting that as it seems to screw half the javascript engine - windows now always open with toolbars (ie parameters are ignored), parents won't close and it seems to open phantom blank windows (doesn't appear in the taskbar). The IE7 uninstall seems to leave a lot of junk in the registry which is causing these problems I think. Ended up putting IE7 back which sorted the javascript stuff but not being able to using running docs is a royal pain.... On another note I think the security prevention features in IE7 are now too restrictive esp. regarding javascript.

We were going to move to VS2005 soon - sounds like a bad idea now if it doesn't work at all with IE7??

Answer 9

the only issue i have with vs2005 is client script debugging.

as i said above, detaching the debugger allows another instance to attach and debug client script.

it's not annoying enough to make me uninstall ie7. 

Answer 10

Hi, I'm having a similar problem, I'm using vs2005 and IE7 and my debugger just doesn't work. I just spent the last two days trying to figure out why IE7 crashed on startup, only to realize its was Google's desktop search, I had to install the new GDS for IE7 to work.
Now finally up and running, debug isn't working. I uninstall IE7 and debug still doesn't work. This is my primary development machine! And I need IE (any version) to work, I have to update our aspx website pages and its hell without a debugger!
Any help would be greatly appreciated!!!

Answer 11

Check whether the debugger statement is of any use .. see this blog entry..

http://mohansmindstorms.spaces.live.com/Blog/cns!69AE1BEA50F1D0E7!233.entry

 

Answer 12

sp1 for 2005 has fixed this problem.  You can all stop crying now, you big bunch of babies.

Answer 13

Yeah and if you read my first post, I was referring to Visual Studio 2003.

Answer 14

Regarding this issue, I have encountered something very similar.

I am working on an application that is heavy on client side scripting running vs 2003 with IE7. Seperating client code out into .js files is really not an option for us.

However, in my case I am unable to even open the aspx file when doubleclicking on it in the Running Documents window. I am able to view code for any .js or .htm files when opening from Running Documents.

Were you able to view atleast the code but unable to step through it? I wanted to make sure I wasn't missing any settings.

I have been unable to find any other resolutions for this issue. Detaching all processes, opening a new debugger instance and attaching the window to be debugged has not worked for me. I am still unable to open the aspx file in Running Documents.

Are there any other workarounds that I am unaware of?

 Any input/help is welcome. Thanks.

Answer 15

Its a year since any replies have been added but I'm having the same problem - FrontPage 2003 (w/IE7) raises an IE script error when clicking on display.  Someone suggested removing the path in the <script> and putting the JS files in the same directory... no affect.  However, I found that if I put the JS files on any drive on my local computer I get the error, but if they are anywhere out on the network FrontPage doesn't raise the error.

Does this make sense to anyone?  Is the problem still related to having IE7 installed?  Any known resolutions?

Answer 16

Hi All.

I probably have encoutered the same problem when trying to debug javascript code written as part of the DHTML behavior. If I have the following html declaration

<td id="a" style="behavior: url(Htc/DropTarget.htc);"></td>

and try to debug corresponding javascript (located in htc file) - it works perfectly fine.
But as soon as I put two or more objects that use the same behavior - I can only debug methods called on events events coming from the last one. For instance in the sample below:

<td id="a" style="behavior: url(Htc/DropTarget.htc);"></td>
<td id="b" style="behavior: url(Htc/DropTarget.htc);"></td>
<td id="c" style="behavior: url(Htc/DropTarget.htc);"></td>

only events coming from the cell with id = "c" will hit the breakpoints in the htc file.

I'm using Visual Studio 2008 and IE8. Are there any patches/workarounds appeared since last post?

Any help would be appreciated. Thank you in advance.

---

Amid