Full of BS » Internet Explorer

Checklist for Embedded IE

John Haugeland — Thu, 24 Aug 2006 02:13:56 +0000

MSHTML is an awesome user interface tool, but it has a whole lot of standard behaviors, many of which aren’t what one wants for an application (since it’s designed for the web.) This is a list of stuff you need to do to embed IE COM and have it behave like a normal application. There’s more than a person might expect.

Suppress the user interface. IE starts with most of its interface turned off, but a few things aren’t. Notable things to include are to suppress the context menu and keyboard navigation.

There are several ways to suppress the context menu. The easiest way is to do it in the html. Add oncontextmenu=”return false;” to your and the problem just goes away, and it’s easily manually overridden for specific elements later.
Alternately, you can override the interface programmatically through IDocHostUIHandler.

Get rid of the OnNavigate noise (the clicking sound when you hit a link.) This is harder than it should be.
Prevent keyboard navigation. If you only ever navigate once, and then do everything else in DHTML, this isn’t an issue, because there’s nothing to go forward or back to. However, if you need to, the way to do this is to capture DWebBrowserEvents2::BeforeNavigate2() and fill its last parameter, VARIANT_BOOL*& Cancel, to true. For security reasons this can’t be done in HTML without a garish ugly dialog box confirmation.
Prevent dragging and dropping links. Do this with BeforeNavigate2() just like keyboard navigation.
Prevent selection. The easiest way to do that is in the HTML by adding onselectstart=”return false;” to the , which is also easily overridden for child elements where appropriate. If you need it programmatically, such as a block which can be turned from and to editability, that’s in IDocHostUIHandler.
Handle some keys directly. Particularly often, control keys, tab and f-keys need very different interpretations in applications than are the defaults in IE. Some keys can be reliably intercepted in JScript, but not all of them. For lightweight stuff, use JScript; it’ll be less painful. However, if you need real control, you need to provide an IDocHostUIHandler::TranslateAccelerator() implementation.
Suppress the interior border. People are often surprised that they turn off the window border in IE, and yet it seems to still appear. That’s because IE’s default stylesheet puts an inset bevel on every web page. Turn that off in CSS by writing body { border: 0; }.
Begin to embed your images and other support media as resources, and access them with the res:// protocol.

One ugly caveat: I have never found any variation of the DirectX PNG alpha filter hack which works with res://, and I’ve looked often and at some very weird variations. It is my current belief that a PNG cannot be embedded through res:// and still be fixed for alpha. This leads to the unfortunate case of requiring at least part of your resources on disk. If anyone knows a way around this, a heads-up would be greatly appreciated.

Set up a system to exchange messages between IE DOM/DHTML/JScript and your application. There are a bujillion ways to do this, but I tend to use a combination of intercepted element events (mostly OnClick in WebBrowserEvents Invoke,) DOM extension behaviors that allow me to call C++ directly from JScript through IDocHostUIHandler::GetExternal(), and executing scripts directly on the DOM object through IHTMLWindow2::execScript().
Build everything in the to be inside a container; make the body itself overflow: none. This prevents several ugly re-layout quirks which we’re used to on the web but not in applications, when content gets long.

Start the container invisible, and make the black. That way, during the lag while resources are being loaded, you have a reasonable appearance. Black flashes look correct. White flashes look broken.
Set an onload=”HandleLoad();” function for the . That way, you know when all resources are loaded, and thus when it’s safe to take the invisible clause off of the main container.
Set the main container position:relative, to make absolute positioning of contained elements easier.

Build your web page in as a resource, and load it through IHtmlDocument2::write(). This allows you to load a document at runtime without using about:blank (which most people use, but which causes a brief white flash before your application loads; very unprofessional looking.) You’ll need SafeArrayAccessData() and SafeArrayUnaccessData() to use write() safely. When it comes time to skin or internationalize, and when you’re dealing with a compile cycle which is just linking, you’ll thank me for this.
Suppress dragging on links and buttons. If you don’t, people will be able to drag them outside the app and onto the desktop as shortcuts, and when followed those shortcuts will lead into your HTML page from the outside (which is, surprisingly, legal.)
Consider compressing your executable, such as with UPX, which makes resources unreadable externally.
Set an id on your . The is considered the origin of most events which don’t have a clear origin, and that means that catching these events is a lot easier (catching by id is the most straightforward way to sort out sources.)
Resist the urge to use runtime styles. They’re not worth the problems they cause.

That should get the new IE user through some common foibles. I’ve probably missed stuff; if you can think of something, lemme know. I do not currently know of a way to embed flash, unfortunately, without leaving available an extra file.

Oh, Neat: A Hack To Fix The IE Click Problem

John Haugeland — Thu, 24 Aug 2006 01:08:44 +0000

I always wondered how applications suppressed that god-awful clicking sound in embedded IE. Usually you catch them screwing with user preferences, but there’s a utility I have which never showed any apparent method of getting rid of the goddamned noise. I always assumed they just styled text to look like a link.

Well, I still don’t know what he does, but I found a way.

Back in post #141, More IE Woes, I documented several problems. One was that MSDN claims this noise cannot be suppressed. Indeed, by design, IE6 refuses to allow you to suppress that sound (god knows why.) That MSDN article goes as far as to tell you to override the user’s sound preferences to turn the noise off. How badbear is that? Anyway, IE7 finally has an interface to turn that off, called FEATURE_DISABLE_NAVIGATION_SOUNDS. However, people like me who are reluctant to make their applications non-functional without IE7 will not like that answer.

It turns out there’s a better way.

There’s a moderately obscure interface from IE5 for IDocHostUIHandler called GetOptionKeyPath. The superficial purpose of this is to allow the IE embedder to create a fake user, so that they can set defaults for IE like the basic font size, background color and so on. This is generally completely ignored in favor of some CSS, but it turns out that this thing actually covers the sound effect scheme too.

All you need to do is use GetOptionKeyPath, create a fake user, override the OnNavigate sound (and maybe some others) to nothing, and let the rest alone, to default to the user’s preferences.

Bang: no more clicky noise, and no overriding preferences, breaking other applications and risking corrupting preferences on crash.

Very clean.

More IE Woes – This Time, from the Inside

John Haugeland — Fri, 23 Jun 2006 02:01:24 +0000

Wow. I haven’t had such mixed feelings about IE in years.

On the one hand, MSHTML – the COM component that implements IE – is actually pretty awesome. I’ve been able to roll applications using it in hours that would normally have taken weeks. It’s an impressive feat of engineering, and though I disagree with some design decisions, the usability of the embeddable component is actually pretty spectacular, if you’re familiar with COM. In particular, the res:// protocol strikes me as borderline brilliant; binary behaviors are awesome; extensible tags have a lot of untapped potential; BHOs would be great except there are too many spamming scum abusing them.

On the other hand, there are problems. There’s one outright boneheaded mistake, and the documentation is sadly lacking.

The OnNavigate sound – that click you hear when you get a link – cannot be suppressed. I’m not joking – by design, IE refuses to let you get rid of it. Their suggestions are to override the user’s global IE preferences, shut off sound, or to hide the browser before you follow any click and then re-show it after the click. Given how much Microsoft blabbed about how this should be usable as a transparent control, it leaves me flabbergasted that they haven’t fixed this until IE7 with FEATURE_DISABLE_NAVIGATION_SOUNDS. Just amazing.

Update: I found a way. MSDN is wrong about this; it is indeed fixable.

This bit about being unable to touch innerHTML on several tag types (notably table and tbody, where it’s hella useful) pisses me off, but since I can work through DOM, it’s annoying rather than important.
One of the particularly wootastic things MS did was to generate an interface called IDocHostUIHandler by which one can inject new functions into JS’ purview through the DOM and window.external , allowing you to effectively provide new interfaces just by implementing a COM object with the automation interfaces in IDispatch. Of course, I can’t find a complete example in pure-c++ without ATL, WTL, MFC or some other ignorant wrapper nonsense to save my life, so I’m pretty stuck. I have a mostly-complete implementation, but when I try to install it, window.external turns to null, suggesting a flaw. Of course, all the error handling is in window.external, where I can’t get at it, so your guess is as good as mine about what’s actually going on.

With some extra documentation and if they hadn’t been such tards about that clicking noise, MSHTML would be a much more wonderful playground than it actually is. (I’m pretty sure there is in fact a way to disable those noises – several commercial applications do it just fine – but MSDN insists it’s unpossible, which suggests it’s probably some undocumented interface somewhere. Hell.)

Sometimes I Forget

John Haugeland — Sun, 01 Jan 2006 06:24:58 +0000

Sometimes I forget just how bad my homepage looks in IE. I’ve just performed a few fixit hacks, but I’m still not happy.

So, I just measured, and approximately 7% of the blogosphere is nonsense whining about Internet Explorer.

Since I’ve just caved and set up a blog, why resist being another one of the sheople? I haven’t complained about IE since IE5.0 was avant garde, and 7’s just coming out; in the fine web tradition of publishing material which is due to be out of date in a few months, let’s get to kvetching.

I just tore a bunch of neat formatting tricks out of my page, because they had been very tenuously hidden in IE with some hacks I don’t care to remake. I installed a few mediawiki extensions (after some editing) and as such needed to change the page framing somewhat. I’m not sure if that’s when the hacks came undone; it seems more likely it was when I upgraded mediawiki, as I may well have forgotten to check my page in IE. The corner icon was misplaced, the framing lines weren’t transparent but an ugly black, et cetera. I also fixed some margins.

Thing is, I’m considering putting ads back onto my page, and getting the right aligned 3rd column was kind of a hassle in Monobook (I use a heavily modified version of MediaWiki’s default stylesheet, which while pretty carries all the code savvy of a bag of hammers; it’s a hackish mess, but it’s too big for me to give enough of a damn to fix.) One particularly nauseatingly awful thing is that the stylesheet, instead of taking the time to hammer out portable correctness, has specialty stylesheets for each major browser which are loaded to deal with native formatting errors.

The maintenance nightmare which erupts as a result is surprisingly awful.

So, the IE7 team has been saying all the right things in their MSDN blogs, about how they want people to abolish the hacks they’ve been perpetrating for older IE, and replace them with modern, accurate stylesheets. It’s weird to think of IE as standards-advocative, but recently they’ve been exactly that, and as much malice as I bear towards the predecessor product, one should give credit where credit is due; this team knows how to talk the talk. (Granted my paranoia suggests they’re doing it to effect browser rollover, but that’s not the point.)

Anyhoo, I have high hopes. The stakes are a little different for me than for most; I use embedded MSHTML extensively. (My god does it piss me off that the directx image alpha filter doesn’t understand res:// .) With appropriate PNG support, a fixed box model and better support for auto margins, many things would be miles and miles easier.

‘Course, this means that I’ll still have to write heredity styling for embedded applications on platforms which don’t yet run IE7; whereas people are tolerant of broken web pages, they aren’t of similarly appearance-broken applications (not that I could blame them.) So, it’s a step in the right direction, but until I start callously cutting people away, it’s not enough.

Still, it’s better than nothing.