Internet Explorer: explorer.exe versus iexplore.exe

For several months, my profile on my home desktop PC was behaving strangely. Over time, the one EXPLORER.EXE process kept growing and growing in resource usage (memory + handles + everything else, it seemed), until eventually it would crash. If I logged out once in a while, and logged back in, I got a fresh EXPLORER.EXE instance with no memory leak. This was not an ideal solution, but it worked for a while.

Well, I recently read an article in the IEBlog, which announced a beta version of the Internet Explorer Developer Toolbar. This toolbar is long overdue, and although I still prefer the Web Developer Toolbar extension for Firefox, this is a big step in the right direction! They do share some similar features, and I use both every day now.

I installed it on my work laptop just fine, but when I tried to install it on my home PC, the toolbar did not show up in IE. I logged in with my wife's profile, and she (someone who doesn't need such a toolbar) could open it just fine. But not me. So, I poked around for quite a while, using various tools such as these 3 freeware tools from Sysinternals: Filemon, Regmon, and ProcessExplorer.

I sat there and compared my laptop with my desktop, with all unnecessary processes stopped or filtered, and tried to watch the effects of toggling the toolbar on and off (On my PC, even though the toolbar would not display, it was listed in the toolbars context menu and could be toggled).

Eventually, I found a major difference. On my laptop, there was one main EXPLORER.EXE process, and then for every Internet Explorer window I had open, there was a separate IEXPLORE.EXE process. On my desktop, there was one EXPLORER.EXE process, and that was it. No matter how many IE windows I had open, it was all running inside one process.

I compared the options in my desktop and laptop network and system settings, because I remembered something in there about launching new processes (in Control Panel Folder Options View, a checkbox called 'Launch folder windows in a separate process'). That was checked on both machines, but didn't affect these web browser windows.

So I did some searching to find out how to change this, and eventually found a relevant message thread which, at the end of the thread (of course), referenced a useful solution.
Add this registry value (and the key, too, if it's not there):

Key:	HKEY_CURRENT_USER\Software\ Microsoft\WindowsCurrentVersion\ Explorer\BrowseNewProcess
Value Name:	BrowseNewProcess
Data Type:	REG_SZ (String Value)
Value Data:	Yes

Phew! Adding that key did the trick, solving both my Developer Toolbar problem and my memory leak problem.

Web pages that capture keypresses are evil!

I hate it when I encounter a web page that tries to be fancy and make its own hotkeys to navigate within the page. Well, I usually hate it anyways. I like that gmail has keyboard shortcuts, and the most important thing is that their keyboard shortcuts are simple (letter keys) and only affect the behavior of the gmail site. They don't capture keypresses that would ordinarily be handled by my browser, like Alt-F (I've depended on that to open the 'File' menu in every web browser since 1995 or so, and most desktop apps as well.

But someone at AOL/Mapquest thought it would be clever to intercept Alt-[key] events (probably not a complete list, just what I noticed):

Alt-F: redirects you to their 'Find It' page (should open browser's 'File' menu)
Alt-D: redirects you to their 'Directions' page (should put cursor focus in browser's 'Location'/'Address' bar, with current location selected)
Alt-M: redirects you to their 'Maps' page (I'm not aware of any default browser behavior for this)
Alt-H: redirects you to their main (Home) page (should open browser's 'Help' menu)

While I applaud them for thinking about keyboard navigation, I don't like their choice of keys.

Another site, Uncyclopedia, captures Alt-keys as well:

Alt-H: move cursor focus to their 'history' tab at the top
Alt-F: move cursor focus to their 'search' box in the sidebar
Alt-E: move cursor focus to their 'view source' tab at the top (should open browser's 'Edit' menu)

Now, there are certainly workarounds that I could use to allow me to continue controlling my browser with the keyboard:

1. Some browser features have multiple keyboard shortcuts; I could force myself to learn different keys.
   
2. I could try to find/create a plug-in/add-on/extension for each of my browsers, to allow me to either:
   1. reassign my browser's keyboard shortcuts to work around these web sites(see #1 above)
      
   2. prevent web pages from being able to capture these keypresses, perhaps with options to toggle this feature for the current site, etc.
3. Stop using web sites that steal my favorite keyboard shortcuts
   
4. Use a different browser, such as Opera (which seems to be immune to the evil put forth by the 2 sites above)

But I just feel like I shouldn't have to do extra work because of these sites... their web developers should respect the common keyboard shortcuts used by the big players in the browser market today (IE and Firefox).

IE assumes .CSV is HTML, Firefox and Opera get it right. [part 2]

[...continued]

So, I decided to try to write a 'bookmarklet' (or 'favelet' as they're sometimes called in the IE world), because I've been finding a lot of useful ones lately, and I often find myself throwing javascript into my address bar by hand to modify a particular page's behavior. Before writing one myself, I searched for a while to see if it's been done already. I wasn't able to find any javascript code to transform a page of .CSV data into a more readable form (namely, an HTML table). I did find a CSV Converter page, which lets you paste CSV data into a textarea (or upload a file) and submit it to a CGI script, which returns the data as either HTML tables or WikiMedia format. I first tried writing a bookmarklet to submit the current page's body to that CGI script.

But that didn't work so well. Part of the problem, from what I could see, is that when IE rendered the page as HTML, the carriage-return/line-feed characters were replaced by a space. This presented a challenge for programatically parsing the CSV text, because now I had to know how many columns existed in the data, so I could figure out where to break the lines, so the table would have more than one row. (My earliest attempts produced a table with only one row, with LOTS of columns)

So, I ended up cheating a little bit, and requiring that the data in the first column on the second row will always be 'IE'. Other than that, the bookmarklet I created can handle more columnns in the future, automatically.

Right click this link and add to Favorites/Bookmarks

If you'd just like to look at the code, click here to see it in a more readable form.

Well, wouldn't you know it... this bookmarklet works in IE 5.01, IE 5.5, Firefox 1.07, and Opera 8.5, but NOT IN IE 6.0. The exact same browser whose shortcomings I was trying to work around. (The earlier IE versions also made the CSV == HTML assumption, but at least my bookmarklet worked in those versions). IE 6.0 did not generate any javascript errors when running the script, nor did it pop up its little security warning bar, or any other visible behavior. It just sat there.

I give up. Stupid IE.

To see the behavior (or lack thereof) of the bookmarklets above:

1. right click it and add it to your favorites/bookmarks


2. go to one of the CSV pages (all 3 files are the same--they just have different extensions):
   
   
   
   • MultiSelectPerformance.csv
     
   • MultiSelectPerformance.csv.txt
     
   • MultiSelectPerformance.csv.html
     
   
   


3. select the bookmarklet from your favorites/bookmarks list to run the script
   

Doing this with different browsers will unfortunately yield different behavior. If anyone can suggest how to make it work in IE 6.0, or how to fix it so it doesn't require 'IE' to be the first value on the second line of the CSV file, I'd love to hear about it!

IE assumes .CSV is HTML, Firefox and Opera get it right.

Sooo... I posted that .csv (comma-separated values) file containing some benchmarks as part of my previous post on the performance differences between browsers when populating multiple select boxes in 2 different ways. What I didn't notice until later, though, is that that file looks like crap if you click the link to it in Internet Explorer. IE seems to make an assumption like "Hmm, it doesn't have extension '.txt', so it must be HTML!" and it renders it as such. Of course, this .csv file doesn't contain any HTML tags, so it doesn't look pretty when IE makes that assumption:
MultiSelectPerformance.csv

For comparison, I made 2 copies of the CSV file:
MultiSelectPerformance.csv.txt
MultiSelectPerformance.csv.html

When I tried clicking the original .csv file link in Firefox and in Opera 8.5, they both behaved as I believe they should. They asked me if I wanted to open the .csv file with the application that is registered in Windows to handle files with that extension, Microsoft Excel, or if I wanted to save it to disk, or cancel.

Screenshots of those dialogs:

It strikes me as odd that IE, with its litigiously tight integration with Windows, didn't bother to check the Windows File Types list before jumping to the strange conclusion that .CSV is a typo for .HTML. It's possible that I could change my web server config files so it would send an appropriate 'Content-type:' header when .CSV files are served. But screw that, this is a stupid behavior in one browser, and I may want to serve a .CSV file on a web server someday where I can't touch the config files. I was determined to do something to handle it on the client side.

[to be continued...]