Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

JavaScript Debugging in a Web Browser Control with Visual Studio


Debugging an embedded Web Browser control in a Windows application can be a pain. The Web Browser control is essentially an embedded instance of the Internet Explorer engine, but it lacks any of the support tooling for debugging.

A few months ago I posted a about using Firebug Lite to provide at least Console output to your JavaScript/HTML based logic. This basically provides an integrated console - based on inline JavaScript - with full support for console logging output including deep object tree access for variables. If all you need is to access a few simple values to check state or other informational settings, this is certainly a quick and easy to go.

Visual Studio Studio HTML Debugging

But if you need to debug more complex code, using Console based output can only get you so far. A few days ago I had introduced a regression bug into the spell checking code in Markdown Monster and man was it tricky to debug. Console debugging had me running in circles.

Right around the same time I got a comment on the Firebug Debugging post that casually mentioned that you can use Script debugging in an EXE application by externally attaching a debugger to the EXE and then choosing Script Debugger. A bit of experimenting ensued...

I vaguely knew that Visual Studio can debug Internet Explorer code, but didn't put the pieces together to see how to do this with my own applications like Markdown Monster that are running an embedded Web Browser control. It didn't occur to me because standalone Windows projects like a WPF app don't offer script debugging as part of the debugging UI.

However it is possible to use Visual Studio for debugging the Web Browser control code, but you need to explicitly attach the debugger to do it. And since you are attaching to a process, it works with any kind of EXE application not just .NET applications.

To set this up:

  • Start up your application from Explorer or Command Line
  • In Visual Studio use Tools->Attach to Process
  • Attach the Debugger to Script Code
  • Pick your EXE from the Process list

Here's what the Attach Dialog should look like:

Once the debugger is attached, Visual Studio automatically tracks any scripts that are running in a Script Documents section in the Solution Explorer and you can open the document from there.

Markdown Monster uses HTML for the Markdown editor and also the preview so both of these pages and their scripts show up in the Script Documents section immediately.

Now to debug code:

  • Open the script file from Script Documents (not from your project!)
  • Set a breakpoint anywhere
  • Run your code to the breakpoint
  • Examine variables by hovering
  • Fix broken sheiit
  • Go on with your bad self!

To open the JavaScript Console and DOM Explorer:

  • Type JavaScript Console into Quick Launch
  • Type DOM Explorer into Quick Launch

Here's what all of this (minus the DOM Explorer) looks like in Visual Studio:

Once you have a breakpoint set you can examine variables and drill into objects just like you'd expect to do in Visual Studio.

You can also open the JavaScript Console which gives you interactive access to the document and script code running in it - just as you would with the regular F12 tools in Internet Explorer. There's also a DOM Explorer that lets you drill into any open document's DOM tree and CSS. These two features use the same F12 tools that you use in full Internet Explorer, just planted into Visual Studio. Usually this wouldn't be so exciting since the F12 tools work fine in IE, but since the Web Browser Control doesn't have a shell and hence no F12 tools support, this fills a big glaring hole in Web Browser Control development.

Watch where you make Code Changes!

If you look at my screen shot you can see that the script file debugged is open and I can edit this file and make changes - if I reload the page (or open a new document in Markdown Monster for example) the change shows up in the executing code.

But be aware that the path to the script file will be in the application's deployment folder, not the file that might live in your project.

In Markdown Monster the Editor and Preview JavaScript code is part of my .NET project as content files that are copied to the output folder when the project builds.

When you debug with the Visual Studio debugger, the files in Script Documents are the actual files running, which are in the deployment folder (ie. \bin\Release). So if you make changes to a script file, make sure you copy those changes back to your project folders after you're done debugging or else the changes are simply overwritten the next time you compile your project.

You've been warned! 😃

I say this because I've done this more than a few times in the past - debugged my files made some changes, then recompiled the .NET project and: Faaaark!, I just overwrote my changes. Don't let that happen to you.

Debug me!

Having full debugging support for the Web Browser Control in my own Windows applications is going to make my life a lot easier. I've made do with Console output based debugging for a long time and while it's a huge step up from no debug support at all it can be tedious. Using the full debugger is a huge leg up when dealing with more complex code in JavaScript.

After I hooked up the debugger in Visual Studio I found my Spellcheck issue in Markdown Monster in a matter of a couple of minutes after previously spending well over an hour with trying to find the right console.log() calls to try and trace down the bug.

Using the Attach to Process is a little cumbersome, and it makes it difficult to debug startup code debugging, but if you really need to debug a complex issue, this little bit of extra work is well worth the effort.

This works with any executable - it doesn't have to be a .NET application like my WPF Markdown Monster app. I have an ancient FoxPro application that also use the Web Browser control and I can debug the HTML/JavaScript code the same way in Visual Studio. Heck even an old MFC application Web Browser would be debuggable this way.

For .NET projects designed for Visual Studio, it would be nice though, if standard EXE debugging would have an additional option to start Script Debugging along side the .NET (or native) debugger, but I can live with Attach Debugger.

I didn't know about this until - well today. And I'm excited - this will make my life a lot easier when I run into JavaScript integration problems. Awesome! Thanks to @Donnchadha for pointing me in the right direction.

this post created with Markdown Monster

I'll be at DevIntersection in Vegas this fall giving sessions on ASP.NET Core with Angular and Localization. Thinking of coming? Use discount code STRAHL and save a few bucks. If you do be sure to stop by and say hello!

ASP.NET DevIntersection 2017. Rick Strahl Coupon Code


The Voices of Reason


 

Ian Oxley
July 18, 2017

# re: JavaScript Debugging in a Web Browser Control with Visual Studio

I remember debugging JavaScript in the WebBrowser control being a right pain. The way I got Visual Studio to debug it was slightly different than what you outlined above:

  1. Make sure script debugging is enabled in Internet Explorer (and restart IE and your app with the WebBrowser control if it was running).
  2. Add a debugger statement to your JavaScript code
  3. Restart the app.

When it hits the debugger statement it should pop up the dialog that asks if you want debug using the current instance of Visual Studio, etc.


Tony
July 20, 2017

# re: JavaScript Debugging in a Web Browser Control with Visual Studio

I have a WinForms app which uses a WebBrowser control which loads an html file using file:\ which loads a third party html editor. I don't see "Script Documents" in Solution Explorer during debugging. Won't this show only for web projects? Isn't MarkdownMonster a WPF app which is like Winforms (both are desktop apps) so come it's showing for you?


Trent
September 28, 2017

# re: JavaScript Debugging in a Web Browser Control with Visual Studio

I've had the same trouble in the past trying to debug embedded script in a .NET application. You can actually make it even easier to debug embedded script by creating a C++ "Empty Project" in Visual Studio. You can then have the project set to run an external application, like the build output from another project in your solution, and set the C++ project to debug Script directly. Finally, set the C++ project as your Startup project.

It takes a couple minutes to set up, but at the end, you can just F5 your solution, set a breakpoint in your script, and watch it break right where you want it to. Of course, the downside to this approach is that you have to have the Visual C++ components installed.

 

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2017