LavaBlast Software Blog

Help your franchise business get to the next level.
AddThis Feed Button

Gotcha: WebKit (Safari 3 and Google Chrome) Bug with ASP.NET AJAX

clock October 20, 2008 23:38 by author JKealey

image Tonight we fixed a severe compatibility issue that I feel you should all be aware of.

Executive summary: ASP.NET AJAX breaks down completely in some circumstances when using WebKit-based browsers. Reference the JavaScript provided below to solve these problems.

As you know, we develop web applications using ASP.NET AJAX and tonight we were notified that one of our users was not able to proceed to the payment page on one of our e-commerce websites. (As you can imagine, preventing payment is the worst thing that can happen in an e-commerce site!). After some investigation, we discovered the user was using Safari 3 on an Intel-based MacBook Pro just like the one I recently purchased. I picked up my MBP and re-tested the site, going through exactly the same steps this user did (thanks to the auditing capabilities we've built into the e-commerce engine). The site works fine in general, except at one particular page deep within the bowels of the website, when clicking on a button, the ASP.NET UpdateProgress control would show and never go away during the asynchronous postback.

I first thought this was an SSL issue such as the evil IE White Screen Bug, but I managed to replicate on my local machine without using SSL. This button is contained inside a dozen layers of user controls. Fortunately, I use this user control in another location. I tested one of these locations (where it isn't as nested) and this one worked. I then proceeded to hide my user controls, layer by layer and narrowed the issue to ASP.NET validators on one of my pages.

<asp:RequiredFieldValidator ID="rfvName" runat="server" ErrorMessage="Required"
    Display="Dynamic" ControlToValidate="txtName"="true" />


Adding Visible="false" to this (and the other validators) on my user control unfroze the UpdateProgress. My first thought was that I must have reached a limit in identifier name lengths because my validator was nested very deeply. I proceeded to rename a few layers to make the name shorter. This changed nothing. I then discovered how to enable a FireBug-like tool in Safari called Web Inspector. This helped me discover an obscure JavaScript error.

Sys.ScriptLoadFailedException: The script 'http://localhost:2241/ScriptResource.axd?[...]' failed to load.


After changing from ScriptMode="Release" to ScriptMode="Debug", I got additional details.

Check for:
Inaccessible path.
Script errors. (IE) Enable 'Display a notification about every script error' under advanced settings.
Missing call to Sys.Application.notifyScriptLoaded().


This finally lead me to an old post on the ASP.NET forums. It appears that Safari 2 needed a few hacks in the ASP.NET AJAX JavaScript code to work properly. These hacks are no longer needed in Safari 3 (or Google Chrome) because WebKit works out of the box. However, these hacks sometimes broke WebKit-based browsers as I discovered today. The first solution in the forums is to change the JavaScript files used by the framework but we didn't like that solution very much. The second comment provided a solution which we found reasonable. 

Workaround

The workaround simply tells ASP.NET AJAX that Safari 3 and Google Chrome are a new type of browser instead of the old Safari for which workarounds had to be programmed.

1) Create a new file called webkit.js

Sys.Browser.WebKit = {}; //Safari 3 is considered WebKit
if( navigator.userAgent.indexOf( 'WebKit/' ) > -1 )
{
  Sys.Browser.agent = Sys.Browser.WebKit;
  Sys.Browser.version = parseFloat( navigator.userAgent.match(/WebKit\/(\d+(\.\d+)?)/)[1]);
  Sys.Browser.name = 'WebKit';
}


2) Reference this webkit.js from your ScriptManager

<ajax:ToolkitScriptManager ID="scripts" runat="server" ScriptMode="Release" EnableHistory="true" 
EnableSecureHistoryState="false" EnablePageMethods="True" CombineScripts="true" 
OnAsyncPostBackError="Page_OnAsyncError" OnNavigate="OnHistoryNavigate">
    <Scripts>
        <asp:ScriptReference Path="~/js/webkit.js" />
    </Scripts>
</ajax:ToolkitScriptManager>


We hope this will help some of you!

kick it on DotNetKicks.com


In 2007, can we afford to refuse potential customers who don’t have JavaScript enabled?

clock November 3, 2007 15:04 by author JKealey

Traditionally, I was very conservative when it came to making use of JavaScript (and even CSS) in my projects. Years ago, I was spending horrendous amounts of time double checking my sites on various browsers, particularly Netscape 4.7. As a developer, I found it was a necessary evil to get the site to work on all browsers, and became quite good at it. I now use Microsoft Virtual PC  to test my websites.

AJAX

A decade after Netscape 4 was launched, I now find myself in a similar position with JavaScript. We need to decide if we can require our users to have JavaScript enabled.  We feel that when used properly, JavaScript can increase the site’s usability. We know that approximately 94% of web users have JavaScript enabled .  Looking at the trends, we can see that this number is rising. We also notice that an increasing amount of websites are using AJAX. However, the big players typically build two versions of their sites, allowing visitors without JavaScript to use their services.   

Maybe a better question would be Can we afford to refuse potential customers who don’t have JavaScript enabled? The answer depends on who your customers are. In the franchisor/franchisee relationship, you can impose stricter constraints on the franchisees, as you don’t have thousands of them. However, the situation is different with the retail customers, who are not technically savvy. They probably have outdated software or half-a-dozen of internet security/anti-virus/anti-spyware packages that compound the problem. (I’ll keep the discussion on the Internet’s culture of fear for another day).

Therefore, by convention, we’d err on the side of caution. This position is further reinforced by the fact that AOL’s browser has broken JavaScript support.  However, taking a deeper look into the economics of the software, we have decided to require JavaScript for one of soon to be released e-commerce sites. I am purposefully omitting many arguments for the sake of conciseness as everything is debatable.

-          Trends: We see an increasing number of sites requiring JavaScript. We’d rather design for the future than the past.  We feel JavaScript has reached its critical mass and can be used in production environments.

-          Return on investment: Given our development style and legacy code, we estimate we need to invest an additional 30% effort to properly support users without JavaScript. This is prohibitively expensive for our clients.

  • New businesses need to start making revenue immediately and hopefully can afford to implement a script-less version when (and if) the site becomes popular.  
  • Our POS (in operation in a controlled environment) uses AJAX profusely.  Re-use is very tempting.
  • The ASP.NET framework includes exceptional server-side controls that make use of JavaScript for postbacks.  We’d have to avoid a large number of useful components or re-implement them.
  • We could develop without script from the ground up (thus eliminating the problem completely), but we feel it limits our potential and usability.

-          We see search engine accessibility as an orthogonal issue. Even if we require JavaScript, we can easily create a few semi-static pages (at a negligible cost) that will be scanned by search engines.  

Still, even after the previous justifications, we are still torn. Concerning accessibility, our position is not justifiable. What “feels right” for us developers (and our customer’s pocket book) will have to be monitored in the coming months. Access logs will be reviewed and customer requests, tracked. We’ll review our decision in a few months and might end up reverting our position in the future.  Therefore, we shall remain conservative in our JavaScript usage, in case we need to review our software at a later date.

I suppose the morale of this story is to be open to change and experimentation.

kick it on DotNetKicks.com


Month List

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017

Sign in