|
|
I didn't read past the first issue of the very long first post, so excuse me if this has already been addressed.
There isn't anything inherently incompatible about .aspx websites and WebKit browsers like Safari/webOS/Android browser. The extension doesn't actually mean anything, other than perhaps to identify which server-side technology (i.e. not on your local machine) that particular website is using. Your browser could care less what the extension is, it could be .fartstain. All that matters is A: whether or not the server is sending you data in response to your request, and B: what kind of data it is.
The problem with item A, that has so long plagued both WebKit and Mozilla browsers especially with regards to financial institutions is that they detect your user-agent (what browser and OS you're using) and block you if it's not Microsoft Internet Explorer running on Windows XP or some other totally arbitrary combination of browser/os.
The reason they do this is to lower their support costs. Especially for highly sensitive sites like those belonging to financial institutions, they have to be extremely rigorous about testing their web applications for security holes and bugs. If they do this on every single browser and device combination, it would be crazy expensive. So they tend to limit it to just a few that they *know* for sure can work, and refuse support for customers that aren't using those.
Or at least, that was the old-fashioned way of thinking. Ten years ago, almost everyone was on Microsoft Windows running IE. Back then, Mac users (the only other group really) were considered acceptable collateral damage. Us super old-time Mac users had experienced this sort of discrimination long before it entered the wider public's radar, and just brushed it off as a small price to pay for our beloved platform.
Today, however, there are soooo many devices, platforms and browsers, most larger consumer-oriented financial institutions have long abandoned that awful hinderance. Unfortunately, many smaller and/or enterprise-oriented institutions remain trapped in that closed mindset.
The *usual* trick around this is to use a browser that allows you to change your user-agent. I'm not sure if the webOS browser lets you do this, but most desktop browsers like Firefox and Safari do.
As for item B, another frequent problem is websites that use IE-specific, non-standard garbage like ActiveX controls. And since .aspx denotes ASP.NET, a Microsoft server-side framework (as opposed to say PHP and Ruby), the two often go hand-in-hand. In those cases, even "faking" another user-agent won't help. So, when you hear people complaining about how awful IE is, and how it acts as a barrier to progress for the entire industry, this is the sort of thing they're talking about.
If I'm mistaken about any of the above, I welcome corrections or objections.
EDIT: I see some talk about user-agent strings a few posts above. I hope my post at least sheds some light on why that alone isn't' always an answer.
|
|
|
Originally Posted by Maverickz
)... do you have any idea what kind of changes could have been made from the original pre to the pre3/TP versions of the browser that would break a website's login behavior? everything worked great on original pre; broken on the new stuff. while i understand .net is all server-side stuff, that's the only common denominator i've been able to find among the sites where i've seen this behavior... so what else could it be? it's pretty clear the browser isn't being blocked, so i don't think it's a lazy developer problem. webkit related?? tia!
