what was i thinking...

IE 9 Bug Not All Links are Right Clickable

Thu, 17 Mar 2011 10:56:00 GMT

Since yesterday I've been using IE 9 most of the time so I can find out if there are any issues in mojoPortal skins and functionality related to using the new version. I use the right click on the mouse all the time for opening links in a new tab, and I began to notice that some links do not show me options for opening the link when I right click it. It seems as if it has no context as being a link and I get the other typical items like to view the source of the page etc.

I noticed it first in Gmail when I tried to right click the Calendar link at the top to open Google Calendar (yes I know it opens in a new tab when you click it normally anyway, but I'm a creature of habit). In other browsers I'm able to right click those links and get a context menu for a link, but not in IE 9.

Next I noticed it in the main menu on www.mojoportal.com

I also cannot right click those links in IE 9 and get options to open the link.

So most links do work with right clicking in IE 9 but some do not, I wanted to fix it, because it seems like a usability issue to me that might confuse some users. I did some trial and error experimenting and I figured out that the cause of the problem is when you have a span wrapping the text inside the link and the span is styled with display:block;

I have not yet figured out a good solution for this. In the case of the mojoportal menu the span is used to hang a background image for the top right corner of the tab and removing the display:block; breaks the design.

I have narrowed it down to a small html example that shows the problem:

IE 9 Usability Right Clicking Links Problem Demo

Not Right-Clickable in IE9 But is Right-Cickable in All Other Browsers

Right-Clickable in IE9

Note that the same problem happens if you use an XHTML doctype, but if you remove the doctype altogether the problem goes away.

So, what do you think? Am I doing something wrong by styling an inline element with block? Is it a bug or a feature of the "most modern web browser"?

I imagine others will find this problem with some designs, though I will say that so far most of the skins/designs we ship with mojoPortal have tested out well in IE 9, so maybe it won't be that common.

Joe Audette ...

SEO Phone Spam

Wed, 30 Jun 2010 15:05:32 GMT

I often get these contact form submissions on joeaudette.com and on mojoportal.com where people are pitching to get my site to the top of google, no big deal, I delete them, but yesterday was the first time I got one by phone.

Yesterday at about 2PM I got a phone call on my cell phone from 951-813-2184 that went like this:

me: hello?
caller: is this the tree service?
me: i think you have the wrong number
caller: are you Source Tree Solutions?
me: that is my company but it is a software company not a tree service
caller: oh, well you're listed in the yellow pages under tree service
me: that's news to me, I didn't know I had a listing in the yellow pages
caller: well are you interested in getting your site to the top of google?
me: oh my God, you gotta be kidding me
caller: well what do you do for advertising
me: Dude! you don't know the first thing about me, my business or my web site, I don't need your SEO spam phone calls, please never call this number again, click

I chuckled for about 15 minutes after that, but hope it is not the start of a trend of spammy phone calls.

Joe Audette ...

Solving the ASP.NET UpdateProgress Div Problem

Mon, 09 Nov 2009 14:58:00 GMT

Introduction - What is the ASP.NET UpdateProgress Control?

The UpdateProgress control is a very handy control meant for use in conjunction with an ASP.NET UpdatePanel. The UpdatePanel is an ajax control that makes it very easy to update part of a page using an ajax postback rather than a full postback. This avoids page flicker and also leaves the page not in a postback state, that is, a subsequent refresh of the browser won't force a postback. The UpdateProgress control is desinged to make it easy to show some markup while the update is happening to give the user a visible cue that something is happening. So a typical trick is to show an animated working indicator something like this

So you would add the UpdateProgress control inside the UpdatePanel something like this:

' alt=' ' />

The Problem - Block Rendering instead of Inline Rendering

The problem is that the UpdateProgress control renders as a div element which is a block element rather than an inline element, so instead of rendering the indicator right next to your button, it renders it below your button on a new line. In some cases that may be ok, but if you really want the indicator to just be right next to the button it's a problem. I came across this situation recently in my work on mojoPortal and I really wanted to show the indicator in the same line as the button, it gave a bad effect for the indicator to jump below the button. So I did some searching on the internet and found a number of people complaining about this problem and a few less than satisfactory suggestions for solving it.

A post on the ASP.NET Forums
ASP.NET Resources post - suggested a way to make it render in the middle rather than below but not really what I was after.
The last comment on the above post suggested using !Important in the css to force inline rendering. I'm not sure if that really works because the javscript associated with the UpdateProgress sets it to block when it shows the content. Also, the !Important is not used by IE 6 unless in standards compliant mode which is not the default and not commonly used in IE 6.
James Van Klink suggested another solution, of wrapping the UpdateProgress inside a span and use absolute positioning on the span. However this produces invalid markup, you are not supposed to nest block elements inside inline elements.
Another solution was posted on stackoverlfow.com, but it seems less elegant than I would like.

So, in summary, the problem is that it renders as a div which is a block element and the javascript associated with the control changes from display:none; to display:block when the UpdatePanel is updating.

The Solution- Borrow The UpdateProgress control from the Mono Project and modify it.

What I really wanted was to make the UpdateProgress control render as a span which is an inline element and I wanted the javascript to toggle between display:none; and display:inline;. Often, when I face a situation where an ASP.NET control cannot be coerced into rendering or behaving as I would like, I have found that I can borrow the Mono Project implementation of the ASP.NET control and modify it to meet my needs. Sometimes its more difficult than others to use this approach depending on what mono internals it may be using, but in this case it was fairly easy.

First I grabbed the UpdateProgress.cs from the Mono source code and added it to my project as UpdateProgressSpan.cs and changed the namespace to match my own project. Then it was fairly simple to change the rendering to use a span instead of a div. However, the problem still remained that the javascript would set the display to block which would still make the span render as a block just like a div. So I scrounged around in the javascript for ms ajax and found the relevant part for UpdateProgress. I copied it into my own javascript file, changed the namespace, and modified it to use display:inline instead of display:block.

The only changes I had to make in my UpdateProgressSpan.cs were:

1. In OnPreRender I had to tell it about my javascript like this:

ScriptReference SRef = new ScriptReference();
SRef.Path = "~/ClientScript/ajaxupdateprogressspan.js";
ScriptManager.Scripts.Add(SRef);
ScriptManager.RegisterScriptControl(this);

2. In Render, I changed it to use Span instead of div and use inline instead of block.

3. In the GetScriptDescriptors method I changed it from referencing the original ms ajax to use my custom one like this:

ScriptControlDescriptor descriptor = new ScriptControlDescriptor("mojo._UpdateProgress", this.ClientID);

Finally in my page I used my custom control instead of te ASP.NET version like this:

' alt=' ' />

Problem solved, the working indicator displays right next to the button.

If you would like to use this in your project, feel free, here is a .zip with the files.

Joe Audette ...

How To Use jQueryUI Tabs in Right To Left Layout

Sat, 09 May 2009 15:00:00 GMT

Recently I've begun using the jQueryUI tabs in mojoPortal as an alternative to YUI tabs. I still like the YUI tabs but there is only 1 skin available currently for YUI tabs, whereas there are a 18 themes for the jQuery UI tabs, so its likely that at least one of them will look good with a particular mojoPortal skin. This has got me thinking about switching to use the jQuery tabs in many or most places where we use YUI tabs. I still need to test a few things like making sure I can use FCKeditor inside the tabs like I can with the YUI tabs. One thing I like about the YUI tabs is that they automatically adjust to right to left layout if they are contained within and element with direction:rtl in the css.

I was worried at first whether the jQuery Tabs would support right to left layout because when I googled for it I could not find any explnations how to make the tabs layout from right to left. I found a number of people asking about it on mailing lists and forums but no-one offering any answers. So I used Firebug to study the css classes assigned to the elements and figured out the things that need to be overridden to make it layout from right to left. I thought I should post it since clearly there are people looking for hep with this. Its actually very straightforward, you include the normal css for the jquery ui theme, and you add another css file below it in the page (it must be lower in the page in order to override the style settings above it in the jquery ui css). There is only a little css needed because we want to override the minimum possible style settings, this is what is needed:

.ui-tabs { direction: rtl; }
.ui-tabs .ui-tabs-nav li.ui-tabs-selected,
.ui-tabs .ui-tabs-nav li.ui-state-default {float: right; }
.ui-tabs .ui-tabs-nav li a { float: right; }

I tested it with all 18 jQuery UI themes and it worked great. I hope this is helpful to others.

Joe Audette ...

System.Configuration.ConfigurationPermission in Medium Trust

Fri, 10 Oct 2008 18:53:40 GMT

As I mentioned in my previous post, I was doing some testing today of mojoPortal under Medium Trust and was trying to resolve some issues. In most situations mojoPortal can be configured to run in Medium Trust, but occasionaly people have reported System.Configuration.ConfigurationPermission exceptions. I have not been able to reproduce that problem on my development machine. I add this to Web.config to configure medium trust for testing purposes:

So today I encountered this exception on a new machine running in Medium Trust. Its not always easy to find out what is causing an exception like this because you don't get a lot of information in the stack trace, but I was able to pin it down to System.Web.Extensions.dll which is the MS AJAX library. We include this dll in the /bin folder with mojoPortal releases and in Full Trust this is ideal because we don't care if the dll is installed on the machine or not, but in Medium Trust, this dll can not run from the bin folder, it must be installed in the GAC (Global Assembly Cache) on the server. If it is installed in the GAC, the copy in the /bin folder will be ignored and the one in the GAC will be used. But if its not installed and the machine is configured for Medium Trust it will cause this mysterious SecurityException with System.Configuration.ConfigurationPermission.

So the reason I was never able to reproduce the problem on my development machine was because I already had this installed in the GAC. If you install the ASP.NET 2.0 AJAX 1.0 using ASPAJAXExtSetup.msi, it installs it in the GAC on your machine. Your only solution to this at a web host is for the host to install it on the server.

Joe Audette ...

log4net Messages Truncated - The Fix!

Fri, 10 Oct 2008 15:37:40 GMT

I was doing some testing today of mojoPortal under Medium Trust and was trying to resolve some issues. In most Medium Trust hosting situations mojoPortal can be configured to run in Medium Trust, but occasionaly people have reported System.Configuration.ConfigurationPermission exceptions. I have not been able to reproduce that problem on my development machine. I add this to Web.config to configure medium trust for testing purposes:

I found this blog post by Phil Haack, where he mentioned that using an external config file with log4net could cause this exception and that moving the configuration into Web.config could solve it. Though he later updated that post and now says that it can work with an external file, I figured it was at least worth a try in case it is log4net causing this exception on some installations of mojoPortal. So I move the configuration into the Web.config file and a strange thing happened, the log messages started getting truncated to about 30 characters. So I did some googling for "log4net messages truncated" and found a number of messages about it but no real solution mentioned so I started reading more of the log4net documentation about the PatternLayout. I thought maybe this truncation was related to PatternLayout so I changed the config to use SimpleLayout and sure enough the messages were no longer truncated. But I wanted to use PatternLayout as I have all along if possible. Originally my configuration was like this:

So I started chopping things out to see if any particular setting was the culprit and indeed it turned out to be the [%property{url}] that was causing the problem. It still seems like a log4net bug, but its strange that it only happens when not using an external config file for log4net.

So for me the solution was just to remove that part of the pattern so my current configuration is like this:

Just figured after all the time I spent figuring this out that I should blog it in case others are having the same trouble.

Now I'm still not sure if moving the log4net configuration into Web.config is going to solve the rogue medium trust issue that happens on some machines. If I can figure that one out it will be worth posting about it as well.

Joe Audette ...

Disabling a button inside an UpdatePanel causes events to fire twice in Firefox

Mon, 29 Sep 2008 18:42:19 GMT

Those of you who do a lot of web development like me are used to occasional issues where client side code doesn't work the same across browsers, but less common and perhaps more pesky are bugs where things run differently on the server depending on the browser. We typically don't expect things to happen differently on the server due to the browser but sometimes they do.

I ran into this strange issue where events were firing twice for postbacks from Firefox but were firing normally when using IE. When you see double postbacks happening in the log, your first thought would be that the impatient user clicked the button twice, but in this case I knew that wasn't true because I was the user and also I have code to disable the button after it is clicked to prevent double postback. There is a very common technique used by many ASP.NET developers to do this. In mojoPortal we have a helper method that encapsulated it so we just pass in the button and text to show when its disabled like this:

UIHelper.DisableButtonAfterClick(
btnUpdate,
Resource.ButtonDisabledPleaseWait,
Page.ClientScript.GetPostBackEventReference(this.btnUpdate, string.Empty) );

and the guts of the method look like this:

public static void DisableButtonAfterClick(
WebControl button,
string disabledText,
string postbackEventReference)
{
if (button == null) return;
button.Attributes.Add("onclick", "this.value='"
+ disabledText
+ "';this.disabled = true;"
+ postbackEventReference);
}

The irony of it is that disabling a button inside an updatepanel actually causes double post back if the browser is Firefox. So the very code we are using to try and prevent double postback actually causes it to happen. All the events fire twice, OnInit, PageLoad and the button click event. Very strange indeed. The symptom doesn't happen in IE, and removing the code that disables the button fixes the problem in Firefox and events fire normally again, that is just once. So we are back to the problem of how to prevent the user from clicking the button twice if the button is inside an UpdatePanel. Our old way works in IE (and works in general outside of UpdatePanels) but actually causes double postback in Firefox.

I did some googling and found where someone else has reported this. I also found a free dll that solves it, but its not open source so I can't use it.

I wish I was posting a solution for this problem, but for the moment I've just gone with not disabling the button. If I find a good solution I'll update this post. but thought it worth mentioning for anyone else who is seeing double postbacks in Firefox. I will say my searches found a number of things that can cause double postback in Firefox, so this isn't the only possible cause to consider. For example if a page has an

Joe Audette ...

Vista 64 bit Is the Place to be for Developing in Visual Studio

Mon, 29 Sep 2008 17:41:23 GMT

I've finally come full circle and am happy developing on Vista again. I was an early adopter and over time I've complained about Vista a few times, so I think its only fair to be just as vocal now that I'm happy with it. In retrospect I think the main problem was that I upgraded a machine that was several years old and it just wasn't powerful enough.

Ever since I got new workstation, development has been a joy, productivity is high. Visual Studio solutions load fast, build fast, and debug fast. With 64 bit Vista you can use a lot more ram. I've got 8 gigs now where before 32 bit Vista/XP could only use 3 gigs. I've got a fast dual core processor (if I had it to do over I would spend more and go quad core). Also 10,000rpm drives make a big difference.

I can't even imagine going back to a 32 bit machine for day to day development. If you are struggling with VS on a slow machine its well worth the investment to get a new 64 bit workstation.

Joe Audette ...

Google Chrome Has Some Shine!

Wed, 03 Sep 2008 23:35:10 GMT

I spent the day today using Google Chrome as my browser and I have to say I'm very impressed with it. I like the UI and its so fast! I've always heard that web kit was fast but never tried it so maybe its web kit that should get the credit since Chrome is based on web kit.

When I first tried mojoPortal this morning using Chrome, the FCKeditor wasn't enabled and it was degrading to a plain text area. This turned out to be just a configuration issue in .NET code I had FCKeditor disabled for Safari. FCKeditor has claimed support for Safari for a while now but when I tested it after their initial support announcement it didn't work for me so I disabled it in mojoPortal. Then I kind of forgot about it for a while since I don't use Safari on a regular basis. Its been several upgrades of FCKeditor since I had tested so I tried enableing it again and it worked fine both in Safari and in Chrome.

So then with more poking around testing things in mojoPortal I found a couple of other things that didn't work like my friendly url suggest feature. It turned out that this was easily fixed by upgrading to the new version of Sarissa. Sarissa is a javascript library I use in a few features in mojoPortal and I had not upgraded it in a long time.

My fixes for these things will be in the mojoPortal svn trunk sometime later tonight and I'll be making a new release soon.

I feel a little worried for Mozilla and Firefox. I've been using Firefox for a long time as my main browser but I have to admit Chrome is very appealing and I may not go back to Firefox as my main browser. Of course I'll continue testing in all the major browsers. Some people are complaining that we now have one more browser to test but so far the rendering of mojoPortal has seemed really good so I'm not too concerned about that. I subscribe to the GAWDS (Guild of Accessible Web Designers) mailing list and there was a lot of talk in the last 2 days about accessibility problems with Chrome particulary for assistive technology like screen readers, but word is there will be improvement on that, after all its just a beta.

I'm sure they will be adding more polish to Chrome, but I would say this beta is a great start. The EULA gives me pause and I hope they change that based on feedback but I give them kudos for the first release. My only other concern is whether use of Chrome is making any more information about me available to google than if I use another browser. If using Chrome meeans sacrificing more privacy than other browsers it won't become my main browser. I also hope that since Silverlight works in Safari, it will also work in Chrome.

I made this post in my blog using Chrome.

Joe Audette ...

My Personal Phone History

Wed, 27 Aug 2008 16:53:55 GMT

These are all the cell phones I've ever had.

I remember when I first got that Samsung clamshell phone on the left, gosh, how long ago was that 1997, 98 99? Somewhere in there I'm sure. I remember being so excited about that phone when I first got it. As a kid I had always fantasized about those communicators they used on Star Trek and when I got this phone it was like the realisation of a childhood dream. I got rid of my land line pretty soon after that and haven't had one since.

I was pretty excited when PocketPC phones first came out. Being a Web Developer, the idea of always having access to the internet wherever my phone worked seemd like a dream. I think I got that phone around 2002 or 2003 and at the time I gave my old phone to my younger brother Frank who lived in North Carolina (I was living in TN at the time). It really wasn't a compelling internet experience, and though I kept it until long after my service contract expired, I got really tired of carrying around that big phone. I mean if you put it in your pocket people were like "hey is that the internet in your pocket or are you just happy to see me?". It was really a phone that needed a belt clip like Batman, but I really wasn't into that belt clip thing.

So then I got the Razr, must have been around 2004 or 2005, again I gave my old PocketPC phone to my younger brother Frank. I was much happier with the Razr, it was slick, it was small, and it was a joy to stop carrying that old boat anchor PocketPC.

Last month I got an iPhone. Its way beyond any phone I ever imagined seeing in my lifetime. Its got a compelling web surfing experience, and yet it fits nicely in your pocket without raising eyebrows. I know a lot of people like a physical keyboard and those folks tend to like Blackberries. I suppose if I was answering a lot of email with my phone I might wish for a real keyboard too. Honestly I haven't yet answered an email with my iPhone. For me its more about knowing whether I have important mail at any time than actually responding to it from my phone. It can usually wait until I'm near a computer again. After all, I'm near a computer about 95% of the time. For me its just another convenient way to service my internet addiction. I work long days and then finally collapse and watch movies at the end of the day when I can no longer keep going. I used to find myself getting up from the couch a lot just to check if any new mail had come in, or see how many people are on mojoPortal.com. Now I don't have to get up off the couch. In some ways I like the Facebook experience better on the iPhone than on a computer. I love having a lot of my music collection in my phone, love the GPS. Its a really great device.

So I thought again whether I should offer my old Razr to my younger brother Frank. The funny thing is, now that I'm living in North Carolina, I find out he never activated or used any of the phones I ever gave him, thats how I'm now able to take a picture of them all together. He hasn't committed to a new phone contract for like eight years now. He's still using this old monstrosity:

We're talking dinosaur phone. Not only that but he relies on this thing for all his communication and he lost the battery charger years ago, so he can only charge it now in his car and he's been doing this for years. I'd say he's way over due for a new phone.

Joe Audette ...