Setting the Default Search Provider to Google in IE

I’ll forever struggle to remember how to configure Internet Explorer 11/10/9/etc to use Google and not Bing when searching from the address bar. Sure you can add providers from the Manage Add-ons menu but it never seems to work for me as the list of search providers that appears on the IE Gallery site—when clicking through from IE itself—doesn’t seem to include Google.

Instead I follow this URL in IE, click the button and tick all the boxes on the popup:

http://www.iegallery.com/en-us/Addons/Details/813

If you found this post helpful, please support my advertisers.

Empty ImageUrl results in empty src and duplicate request

Not exactly a new issue but an empty ASP.NET ImageUrl tripped us up today. In this case there were no visible symptoms but two requests were coming through when Fiddlering the page view: the first initiated by the user and the second initiated by the page itself towards the end of the trace. In development with a debugger attached, this was manifest with Page_Load, CreateChildControls, etc being called twice for no obvious reason.

Because I initially thought I introduced the problem with the control I was working on, I first attempted to convince ASP.NET CreateChildControls was complete; I did so by clearing the Controls collection before unleashing my own code and setting the ChildControlsCreated property true once done. Neither of these tricks had any affect and the Fiddler trace had me convinced something beyond the ASP.NET pipeline and IIS had to be at fault.

That turned out to be the case but ASP.NET was still to blame ;-)

Specifically, we were adding a server-side ASP.NET image control but not initialising its ImageUrl property; the image src was later being set by jQuery at runtime on the client side. As mentioned, there were no visible symptoms of the double request: the image src was set as expected by jQuery and everything appeared okay on the surface. The IE dev toolbar also showed image src as being correctly set and there were no 404s in the mix.

It wasn't until we looked at the raw HTML that our ever-faithful admin extraordinaire noticed the empty src="" attribute. Removing the attribute removed the problem so I can only conclude IE is helpful enough to attempt to interpret a request for an empty image as a request for the parent directory of the current page while parsing the HTML before any Javascript runs. Thanks again, IE!

Notably this problem wasn't reproducible in Firefox or Chrome.

To fix the problem, we first set a default value for the ImageUrl property but that left me feeling dirty since it was still resulting in an unnecessary request. When I realised the server-side Image tag wasn't actually being used for anything server-side anyway, I replaced it with a boring old HTML img tag with no src. Microsoft has other, equally lame workarounds for this if you're interested; note they also don't plan to fix this bug.

If you found this post helpful, please support my advertisers.

CSS background-position not applied

Had a weird issue with a CSS sprite this morning where both IE8 and Firefox ignoring the background-position style. After stripping the component back to bare bones, the style started working as expected; I was momentarily stumped until a co-worker spotted the fact I didn't have any units specified for the x and y coordinates. Adding px to each coordinate resolved the issue.

.addLeg
{
    background-image: url(Buttons.png);
    background-position: -10px -70px;
    width: 143px;
    height: 30px;
}

Doh! That's what I get for copying code from the internet! Maybe something to do with the nesting or inherited styles? Who knows…

In related news, I also noticed the IE Dev Toolbar in IE8 is inclined to display additional styles seemingly appended to the background-image style. This is a minor annoyance in terms of being able to manipulate the appended style but it seems to be a bug with the toolbar, not IE as the styles are applied correctly.

IE8 dev toolbar disable script menu grayed out

The Disable –> Script menu option in the IE dev toolbar has baffled me for a while now: sometimes it’s enabled, sometimes it’s disabled (as in grayed out and unselectable), and whenever I need to use it I can’t. I’ve also noticed some of the tabs (namely Script and Profiler) occasionally disappear—easily solved by restarting IE—so I’ve put down the Script menu issue to bugginess. Thankfully the IE(6/7) Dev Toolbar download page makes clear that “Some menu items are unavailable (grayed out) when running Internet Explorer in Protected Mode on Windows Vista.” I’m running Windows Server 2008 R2 with User Access Control intact and, sure enough, opening IE by right-clicking the IE icon and selecting Run as administrator enables the Script option.

With the IE dev toolbar now built into IE8 and IE being the defacto intranet/corporate browser that it is, I can see why this would be locked down for non-admins; I suppose you don’t want those pesky information workers and power users hacking your corporate forms. What a hassle though.

.

CMYK .jpg images don’t render in IE and Firefox

For the second time in recent memory I was today faced with a "broken" image in IE 8 and Firefox 2.x due to the image being saved using the CMYK colour mode instead of RGB. Interestingly, Chrome was quite happy to display the image as it was; I had to open it in Photoshop, change the mode to RGB, and save it back for the other browsers to respond. Apparently saving for web does the same thing.

Here’s the image in CMYK:

 And here it is again in RGB:

IE8 Slow to Load, Slow to Create New Tabs

I don’t use IE much ‘cause I’m a huge Chrome fanboy and Firefox is the obvious tool of choice for most things web dev. That said, with integrated authentication IE just works better with SharePoint and TFS to the point where I’m pretty much forced to leave it set as my default browser.

I had very high hopes for IE8 and the latest version of the IE Developer Toolbar; I now feel let down. Apart from the default install being horribly slow to load and create new tabs (I timed it around 8-9s), I’ve found the IE Dev Toolbar to be less intuitive and very ugly compared to the old standalone IE Dev Toolbar and of course Firebug.

The one thing I really love is the ability to force new windows and pop-ups into new tabs—again because of the way SharePoint won’t let you right-click/open in new tab when viewing a page and the TFS web interface sprawls new windows.

I’m on an ancient XP machine that sucks at everything so at first I thought the speed was just me. Googling “IE8 slow” however quickly pointed me to Ed Botts’ post that suggests registering a specific DLL and rebooting. I’m not alone after all, I thought to myself, and promptly registered the DLL and rebooted with no change.

I gave up for a while at that point until I came back to the issue today. Raphael’s post countering Ed Bott’s post, which I’d also read previously, is now full of comments suggesting different remedies. One particular comment suggested disabling add ons and Java in particular.

So I dove in and disabled all of my unused add ons, noting the load time value against the Java item. I imagine Doing so fixed the problems and I can load new tabs in roughly half a second.

I hate Java apps and generally have no need for the add on so I guess I’ll just leave it disabled. The same commenter mentioned also indicated updating Java to the latest version didn’t help.

It seems like each new IE8 tab fires off its own process so I can see how add ons would need to be loaded every time a new tab is created but compare the listed load time of 2.49s versus the others at 0.01s and it’s both shocking that IE will allow this to happen and Sun think they can get away with this.

Historical Flash Player Versions

If you've ever needed to test against an older version of the Flash browser plug-in, Adobe has an archive available of all versions back to v2. Instructions are also available for uninstalling existing versions.

http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_14266

IE Renders Spurious '#text' Node as a Gap

I today had the misfortune of discovering IE6/7 doesn't like to display relatively "normal" HTML.

Take a look at this code and the bolded DIV in particular:

<html><body>
<style>
* { padding: 0px; margin: 0px; }
img { border-width: 0px; }
</style>
<div>
<img src="pic.gif" />
</div>
<div style="width: 285px; height: 100px; background-color: Green;">
<p>Other stuff</p>
</div>
</body></html>

This renders a lovely gap between the image in the top DIV and the bottom DIV:

Inspecting the DOM using the IE Developer Toolbar reveals IE is interpreting and rendering a spurious text node from the markup:

As you might expect, Firefox has no issues with this and renders the two DIVs one on top of the other with no gap between.

Despite average CSS skills, I was unable to style this into submission without completely mangling the existing code and CSS (simply adjusting the DIV's height had no effect); instead I managed to get around this by simply removing all whitespace between the opening and closing DIV tags:

<div><img src="pic.gif" /></div>

Since the image in this example is essentially functioning as background image for the DIV, I could have alternatively set its background-image to the URL of the image.