Google Chrome: first impressions

So, we've got a new kid on the browser-block: Google Chrome.

Fist thing that came to mind?  Crrrap! 

Let me explain why I'm not sure I like the idea: from a web developers' point of view, a new browser version most of the time just means "more compatibility issues".  Let alone this Chrome-thingie: not just a new browser version, but a completely new browser altogether.  Well, new... it uses WebKit, the open source browser tech also used by Safari.  And yes, WebKit is more standards compliant than IE or FF - but in reality, sites are built to work on IE & FF.  Safari-compliancy is a nice extra, nothing more.

That said, I can't just ignore this.  Sure, Google Chrome is in beta, but it won't be long 'till we get requests from clients asking if their web apps will continue to work on Chrome.  Hell, it's Google, not some little unknown company, so you can be sure lots of people will know about and start to use this browser pretty soon - even if they're just curious about taking it for a spin. 

So I downloaded and installed it (very fluid and fast process, btw), ran it (huh? This viewport is huge!) and surfed to some random sites on it, which all seemed to load faster than what I was used to.

First impressions?  I'm impressed!

Well, that good impression didn't last too long. 

Actually, it lasted right until I fired up one of the apps we developed - and there you had it, just as the doctor ordered: browser incompatibilities.  It took us quite some effort to get that webapp to display more or less the same in Firefox 2, IE6 & IE7 (and the CSS is not even that advanced).  Then, along came FireFox 3 - and changes had to be made (for those of you who still believe a site that displays correctly in FF2 will do the same in FF3: sorry to burst that bubble ;-)).  And now Chrome comes along...  all of a sudden, buttons take up double their size (because the containing text doesn't fit on one line anymore), upload-controls look just plain ugly, and Chrome insists on giving every selected textbox a little 3D-ish yellow border.  Which, incidently, is exactly the look I'm aiming for in one of my Silverlight-apps, so maybe I should sue 'em for stealing my colours or something ;-) 

But, on the good side: the app is still completely functional - everything works as it should, it just looks a bit weird.   Chrome just gives it a bit of a Picasso-touch, if you wish ;-).  And next to that: the app is running pretty fast.  I guess the fact that it's quite heavy on javascript (Chrome has a new JS-engine) has something to do with that. Up until now, our web app was fastest in IE7 by far, followed by FF3, 2 & IE6.  Up until now, 'cause Chrome quite easily beats IE7 to the top spot.

A few other things: yes, Chrome crashes from time to time - but it's still beta, that can be expected.  Also, one of the big features Google is claiming (the "one process per tab"-thingie, which would mean that one crashing tab doesn't affect the other tabs) is actually already in IE8 beta.

So, in a dramatic turn of events, now Google is the one stealing from MS instead of the other way around.  Or wait, let me rephrase that: I meant "being inspired by MS" ;-)  Nah, just kidding: no need to call it stealing.  You see a good feature from another company, you want to include it in your own app - nothing wrong with that.

A quick conclusion?  I don't like the lack of support for stuff like Silverlight - really, stuff like that (which actually takes care of CSS/browser-incompatibilities for me) should be supported out of the box.  I dislike the fact that this new browser gives me even more work trying to get my sites & web apps to look the same in all browsers. It has a few security issues.  And it has problems displaying WSS & SharePoint-sites.

But as far as my regular surfing is concerned: most sites work, and I absolutely love the speed & big viewport of this thing!  FireFox never really "did it" for me: the only feature I'd really like in IE7 (out of the box, that is) which FireFox has is inline searching, but next to that: couldn't care less for the 100's of plug-ins. 

Let's put it like this: for regular surfing, I like my browsers clean, nice-looking & fast.  Up until now, that meant using IE7.  But Chrome is faster, has a less cluttered user interface, and a bigger viewport.  So as far as I'm concerned, Google might just have a real contender up its sleeve with Chrome - I, for one, am pretty sure I'll be using it a lot in the near future.

AJAX & Validation of ViewState MAC

Quick post (which apparently has been sitting in my drafts for a few weeks, woops ;-)): ever had an error looking like this when using an AJAX-intensive webapp? 

Validation of viewstate MAC failed.  If this application is hosted by a Web Farm or cluster, ensure that  configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

or an "Invalid postback or callback argument"-error, coming from the PageRequestManager or ScriptManager?  And you're not on a Web Farm nor cluster?

In more detail: you get the error ad random, not on all machines, not all the time?  Well, so did we.  As you are well aware, errors that seem to happen at random and only on some machines are quite difficult to debug.  In this case, we had our application installed on a standard W3K-server (virtual server).  When I would surf to the app and use it from my laptop, it worked as it should.  However, when one of my collegues surfed to the same site, she randomly got the above error.

Well, apparently this has got something to do with the ViewState being encrypted: when you encrypt your ViewState, an encrypted ViewState field is added just before the closing of the <form>-tag.  However, when you make a postback before the page is fully rendered, the postback is initiated without this field => thus, throws an error.  You can already imagine why this happens with AJAX (ie, partial postbacks) a bit more often ;-)

Solution is easy: in your web.config, in the <pages>-tag, disable EventValidation (enableeventvalidation="false"), and set the encryptionmode to Never (viewstateencryptionmode="Never").  Problem solved!

One quick word of advice: do not do this if you don't have enough other security checks to make sure your viewstate hasn't been tampered with (or enough validation to make sure this gets caught later on in the app).  Another way around this is to disable your form on every (partial) postback.