Firefox 5 introduced auto-updating. I noticed that my installation of FF5 has already updated itself to version 6.
Does this mean that, like older versions of Chrome, Firefox 5 doesn't really need to be included in my cross-browser testing battery? Or is there a way some users may prevent it from updating that I should worry about?
Though it "auto-updates", I'm always given the choice to do so.
For instance, I often don't install the update until I know my add-ins (especially FireBug) are not flagged as being disabled with the new version. This, among other contingencies, may suggest to keep FF5 support.
Always include Firefox 5 cause there are plenty of developers and users that somehow have disabled the auto update feature for whatever reason they have.
The user can, as said by Brad, always make the choice to update or not. They could edit some registry values or just using about:config, so always include FF5, etc..
You should look at the statistics when making such decisions. At this point, only 12% of Firefox users are using Firefox 5, with 55% being on Firefox 6. For comparison: Firefox 3.6.x is still being used by 20% of the users, Firefox 4 by 5% of the users.
I think that once the old branches (especially Firefox 3.6) expire you will indeed be able to concentrate on the latest Firefox release. The current tendency is that the previous release becomes irrelevant two weeks after its successor is released. While there will always be some who turn off auto-updates, the numbers are pleasantly low.
Source of statistical data: https://addons.mozilla.org/en-US/statistics/addon/1865. Feel free to compare with other sources.
Does this mean that, like older versions of Chrome, Firefox 5 doesn't really need to be included in my cross-browser testing battery?
If you are going to support older version you should always test it with older versions.
Auto-update can be disabled on most (/ all?) platforms.
I would say for your applications sake that you use AT LEAST one previous version of the popular browsers as well as their current addition when testing. Many people take awhile to update or never update. A large portion of the business world still uses IE6 for instance.
If you are maintaining a production site, perhaps monitor your web analytics to see what percentage of your users are lingering on FF5. That'll determine how best to serve your users.
As for the topic of auto-update taking hold, there could be any number of reasons why users lag. I declined to update to FF6 on my local machine the first few times it offered to, for fear of a few beloved developer plugins breaking. Unnecessarily cautious, in this case...
Firefox has a checkbox in preferences that lets you disable updates if desired. So yes, users can turn off updates.
Related
In VERY laymans terms - three questions if I can:
First, my understanding was that Comp Mode provided some rendering assistance (IE9?)- and that EMI provided the rendering further back (IE8) (along with some of the Speed enhancements) - Is this correct?
Second, it has been suggested to me that the natural progression to test compatibility would be:
Native
EMI
COMP
EMI and Comp
I would have thought (based on my understanding) that it would be:
* Native
* Comp Mode
* EMI
Finally, is it feasible and what is the benefit to put the website into EMI AND Comp Mode?
For some users, features like enterprise IE (EMIE), compatibility view, and the other document modes are useful because they make recent versions of IE11 behave like older versions of the browser. For example, EMIE makes IE11 behave like IE8.
Why would you want this? After all IE11 supports many more standards that IE8 did. IE11 is more consistent with other browsers than IE8 was. These make it easier to create public websites that behave consistently when used by other browsers or devices.
The compatibility features, however, are meant to help those trying to maintain older applications, applications that depend on feature that IE11 no longer supports for whatever reason.
I think what you call comp mode is what MS calls compatibility view, which puts recent versions of IE into a mode similar to IE7. There are other modes available, called document modes, that put IE into modes designed to emulate earlier versions of the browser. There's a mode for each version from IE7 to IE10 as well as a mode similar to IE5 and earlier. The IE7 document mode is essentially the same as compatibility view.
The problem is that the document modes (and compatibility view) are all approximations of earlier versions. They're not perfect emulations. In many cases, they're enough to help an application work.
EMIE is a specialized mode designed to better emulate the behavior of IE8. For some companies, EMIE helps an older application run even when it doesn't run in IE8 document mode. Why? Because those apps were written based on the features and behavior supported by that version of the browser.
If you're testing applications, I would say the best approach is to run the app in whatever mode is default with the new version of IE. Use the developer tools (or even the scanner on modern.ie) to help identify problems and then update the app to work accordingly. This requires an investment of time, energy, and money that some are unwilling to make. (I would argue that this is short-sighted in the long run, but the mileage of others may vary.)
Barring that, I would use the developer tools to switch to different document modes to see if the application can be made to run until such time it can be updated. If you find a document mode that works, then you use the appropriate 'x-ua-compatible' header to enable that document mode.
If there isn't an appropriate document mode and the app worked fine in IE8, then EMIE might be a useful too. You enable that using group policies or registry keys.
There is a lot of information available to help fill in the gaps of this explanation. Here are a few to get you started:
Defining document compatibility
Specifying legacy compatibility modes
The IE Compatibility Cookbook
What is Enterprise mode?
Chris Jackson's AppCompat Guy blog.
In the end, you'll need to investigate the apps that are causing problems and determine an appropriate course of action based on the resources and priorities of your organization.
Hope this helps...
-- Lance
I have a Firefox extension that supports Firefox 3+, and SQLite database is important for my extension. I saw on the MDN that the API might change and it`s "unfrozen", should I be worried about it?
The API is currently "unfrozen", which means it is subject to change
at any time; in fact, it has changed somewhat with each release of
Firefox since it was introduced, and will likely continue to do so for
a while.
This warning is probably outdated, it has been added to the original version of the document years ago and hasn't been updated since. Fact is, starting with Firefox 4 all APIs are unfrozen and could change. But that shouldn't really be a reason to worry. As SQLite access goes, the API seems pretty mature by now and Mozilla developers are mostly tweaking performance without introducing breaking changes. The most important change was the introduction of asynchronous API in Firefox 3.5 and the deprecation of the synchronous API. But as long as you only use asynchronous API you should be on the safe side (I cannot imagine that you really need to support the ancient Firefox 3.0 release, I guess that you actually meant Firefox 3.6).
For something so widely used I doubt it but it's easy enough to write code to work around that and keep your addon backwards compatible (at least in javascript). What I ended up doing is abstracting away methods that did change and wrapping them in my own calls that would do something like
if (methodInFF3) doFF3Method();
else doNewMethod();
or something like that. This way when things changed I only had to change the code in one place instead of many but then again the first time it happened I had to change the code everywhere. For SQLite I probably wouldn't worry too much though but that's just me, just make sure that when a new release comes out you check the docs to see if anything has been changed and you should be fine.
In order to test CSS in different browsers, do I have to result to installing each browser on my development system? Isn't there a useful program where you can just load an html+css file and view how it's rendered in different modern browsers?
If you're after a professional solution, take a look at Litmus.
Nope, you have to have those browsers installed in some form, although there is software such as IE Tester which will allow you to open tabs as IE5.0 - IE8. There are also online services such as:
https://browserlab.adobe.com/index.htm
Free Service
Limited # of browsers Available
http://crossbrowsertesting.com
Paid Service
http://browsershots.org/
Free Service
Supports INSANE # of browsers
It can take a long time - I've had it take an hour to return screen shots during peak usage. Can be as fast as 2 minutes for a dozen browsers.
Which will let you view your site in multiple browsers.
If you want 3 engines in one browser check Lunascape.
Additionally for all Internet Explorer versions you have IEtester.
I need to upgrade a ASP.NET website for IE8. it works fine in IE6, but not in IE8. I don't want to run it in any backward compatibility mode. I would like to make any code changes that are required to make it fully compliant with IE8/Firefox. what is the best and/or easiest way to do that? is it just a case of going through each of the things that are broken and fixing them one by one or is there a more efficient way to fix these issues (some kind of utility??). thanks in advance.
Well there is no tool or utility to fix cross browser compatibility issues. You can make use of firebug(firefox) and IE developer toolbar to identify the points where the website is breaking.
But the good part is that you are upgrading from IE6. I dont think there will be major hiccups or problems making the website compatible with IE8 since its much better in rendering HTML as compared to IE6.
If you have expression web, you could use SuperPreview: http://expression.microsoft.com/en-us/dd565874.aspx
THis is a great tool that allows you to compare you site in different browsers.
Yes, you do have to go through each browser incompatibility bug and fix it for that browser. A bug can be fixed in 3 ways (listed in my order of preference):
Start with a very compliant browser, then look at the page in other browsers (I focus on Chrome/Safari/Firefox/IE6-7-8-9)
Use different CSS technique, that ends up rendering the same in all browsers
Use IE Conditional Comments to bring in another CSS for that browser leveraging the CSS "Cascade"
Use CSS Hacks as a last resort (usually only for Firefox or something)
But "go through each browser" can be the tricky part! There are some tools to help.
#Brian mentioned SuperPreview for Expression Web (+1), but there's also a free version of SuperPreview for Internet Explorer for those who don't have Expression Web.
You can compare different versions of IE on the same machine (hard before this product). Microsoft claims this sub-set of the Expression Web product will always be free (since they feel bad about IE6!).
IE6-7-8-9 tool is good enough for me, because I tend to focus on all versions of IE, but only the latest versions of Chrome/Safari/Firefox.
But if you must test against multiple versions of other browsers:
Expression Web SuperPreview
How to Use Multiple Browsers on a Single Machine
10 Helpful Resources for Cross Browser Testing
(Although Litmus seems to have dropped general web page support, and instead focuses on email client compatibility and campaign analytics.)
MSDN makes it sound so easy to detect a mobile browser:
if (Request.Browser["IsMobileDevice"] == "true" )
{
Response.Redirect("MobileDefault.aspx");
}
Actually, it looks like you can also just check Request.Browser.IsMobileDevice. But how does this actually work? I don't even have a .browser file... what's going on behind the scenes here? Are there some built-in defaults for ASP.NET 2.0?
A number of *.browser files are shipped with .NET:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers
The runtime uses regular expressions from the *.browser files to match against the incoming User-Agent string, and then sets a bunch of properties based on each match it finds (there can be several in the hierarchy).
If you need in-depth mobile device support, consider installing the MDBF, which adds support for about 400 devices:
http://mdbf.codeplex.com/
Now, after 4 years, it's even more simple
Request.Browser.IsMobileDevice
Since for most sites, it is actually the size of the screen that matters and not so much the capabilities (at least when talking about modern phones with things like Safari and Chrome on them) wouldn't checking the resolution make the most sense?
Request.Browser.ScreenPixelsHeight
and
Request.Browser.ScreenPixelsWidth
I wouldn't rely on the MSDN link, there is no common standard unfortunately for mobile browsers and many try to mimic their non-mobile counterparts. Also it will return true if it doesn't recognize. See this link.
My current understanding is that there's just one exact solution to the problem of detecting whether a browser is mobile and next detecting its real capabilities. This solution is ScientiaMobile's WURFL (http://www.scientiamobile.com). Which, as of Aug30, is no longer free for every use. WURFL is now released with an ASP.NET API under AGPL. The data repository also comes with a specific license that disallows both copying and using with APIs different from the standard one (unless one purchases a commercial license).
So for practical purposes other approaches such as 51Degrees cannot be used with more recent and future versions of the WURFL repository and this will make it difficult for 51Degrees to detect new devices (Windows Phone 7.5, for example).
As for MDBF (a dismissed project), it may still work to detect whether a device is mobile (much better than the IsMobileDevice in ASP.NET). It is not entirely reliable as far as properties of the device are concerned. It insists that my HTC Desire Android has a 240x320 screen size, which is patently incorrect.
My company bought a WURFL license and we're absolutely OK with that.
Issues has been resolved while I added 51Degrees, just add 51degrees using Nuget thats all. See more here https://51degrees.codeplex.com
Simply use below code,
if (Request.Browser.IsMobileDevice)
{
Response.Redirect("MobileDefault.aspx");
}