Lately, we have noticed that not all Firefox versions are playing the same game when it comes to layout and I wanted to find out if there is a definitive guideline when it comes to developing for Firefox.
What we're having to do is use Portable Versions of FF and then test across these versions but this is becoming a major headache! If someone knows of a script that will fix these issues across different versions of Firefox, I would appreciate it. Else, if there is some guidelines I can follow, I would appreciate that too!
Thanks,
James
The behavior you see might be an intentional change (e.g. to comply with the HTML5 spec) or a bug (a regression). If it is the former it should be listed on https://developer.mozilla.org/en/Firefox_4_for_developers or https://developer.mozilla.org/en/Firefox_5_for_developers. These pages are usually created in advance of a major release (e.g. https://developer.mozilla.org/en/Firefox_6_for_developers exists already) so that you can see if something affecting you is coming up. If a change breaks backwards compatibility there should be hints on how web developers can deal with it.
If it is a bug then it should be reported on https://bugzilla.mozilla.org/ along with a minimized testcase, marked with the "regression" keyword. Regressions that are reproducible and that affect web applications usually get looked at pretty quickly.
That's a very broad answer to a very broad question. For more useful answers you should really provide some details with your question.
Related
I use Firefox for about 90% of my overall browser usage experience and periodically discover bugs or strangeness in work, also from time to time I have suggestions for improvement.
So I think that it's useful for Firefox community to know about potential or actual problems. Is there such resource to create quick reports (I'm at work, for example, and haven't enough time for advanced conversations)? What is the easiest way to report bugs and suggest some new ideas? May be there is some addon for this purpose?
Thanks in advance.
Good question! Depending on the problem you are seeing, there are different strategies for efficiently reporting the issue. Efficiency in this case means the reduction of the time that passes from your report to actually get somebody to take a look at it (and then decide what's next).
Here's a set of ways you can use to get in touch with the community (disclaimer: I'm part of it):
Bugzilla: it's the one stop place for reporting bugs for Firefox. I know it's a bit cryptic at first, and there are plans to improve the bug reporting workflow. There's a comprehensive article on MDN that explains how to write a good bug report that's actually helpful. Don't get mislead by the word "bug": Bugzilla is also used to track the development workflow and discuss enhancements.
webcompat.com: if you're having problems with a particular website that doesn't get rendered properly, you could still write a bug report in Bugzilla. However, the webcompat website (still supported by Mozilla) is more suited for this kind of things. It also features a downloadable Firefox addon to speed up filing website compatibility issues.
Github: some components (Testpilot, ...) live on Github rather than in the central Mozilla repository. If you're experiencing issues with them, you could file an issue on the github page for the specific project.
irc.mozilla.org: (discontinued) this chat server allows to get in touch in real-time with the Mozilla community. There are several channels you can hang out in, even using a web-based IRC client. People are usually very willing to help. This is not the best place to report problems, but still a good place to raise awareness about your bug if it doesn't get triaged (i.e. assigned a priority and discussed) within a week or so.
chat.mozilla.org: as of May 2020, this replaced IRC and is the new recommended mechanism for synchronous communications. See the related wiki.
I know that's a lot of info, but it's easier than you think! If you feel like you don't know where to file bugs, just go to Bugzilla. Please do not hesitate to ask if you need more help and.. cheers for willing to report bugs!
Updated May 2020: Added Matrix and marked IRC as discontinued.
When I’m programming a Web app and I run into a problem that only seems to happen in one browser, I know that a somewhat-essential step among my overall programming tasks as a “good citizen” is to stop coding for a bit and take time to report the bug in the right place—so it can get fixed and other Web developers (including me) hopefully won’t run into the same problem later.
In such cases with Firefox, I understand enough to know when the cause of the programming problem I’m seeing is in the core “Gecko” browser-engine code in Firefox (rather than instead being, say, a bug in the Firefox user-interface code—the code for the so-called browser “chrome”).
Given that, is there a URL that will take me directly the form where I can quickly get to the right bugzilla “product” and “component” to report a Gecko browser-engine bug against?
Having already reported a few bugs in the Gecko code, I am somewhat annoyed at being forced to use the form at https://bugzilla.mozilla.org/enter_bug.cgi, which seems to assume I’m reporting a bug for the first time and I want guided step-by-step help. But this ain’t my first barbecue…
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&format=default is the URL you want.
That’s because in the case of Firefox, the right bugzilla “product” to use for browser-engine (Gecko) bugs is actually Core (not the Firefox component—and there is no Gecko component).
That URL above takes you directly to an actual bug-reporting page—that is, as you’d want, it completely skips all the designed-for-first-time-bug-reporters step-by-step guided-help stuff.
You do need to then manually choose the right “component” from the Component list there, but if you already know the right component, you can make a bookmark that includes it; e.g., https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=DOM%3A%20Workers&format=default is a URL that will let you report problems with Firefox Web-Workers behavior.
Adding the &format=__default__ parameter/value is the important part needed to get bugzilla to skip all the designed-for-first-time-bug-reporters step-by-step guided-help stuff.
I have the source code from a plugin for second life to play in a browser but the problem is it's been created for Firefox 3.5, so what I'm trying to do is to bring it up to speed and upgrade it to the current Firefox.
Unfortunately I'm not sure how to go about this as I am literally just looking into this now, any help is greatly appreciated
What's your main aim here? Are you interested in simply making the extension work somehow in the latest firefox or are you more interested in optimizing performance?
Optimization of an application is a very general topic. You can look into the upgrades Gecko has gone through in the recent versions. If there seems to be any specific module for which Gecko is now offering a better interface/compatibility, you might try adapting the same. Again, this is really the programmer's judgment and skill which lets him draw the boundary between feasible and non-feasible development. For a module which is extensively linked with many other modules, it might be a good idea to leave it as it is to avoid sleepless nights (of course that's just my opinion. For some, that is the real kick :D).
If you are interested in creating high-performance plugins, you might like to give Google Web Toolkit a try. It is a Java library which compiles java into optimized javascript introducing various performance oriented quirks. I understand that it is not possible to switch an entire application to GWT easily and wouldn't help you just now, but I think it is worth mentioning for future use.
On the other hand, if you are just interested in making the extension work, you may look into Nightly Tester Tools, which is an extension used to override add on compatibility.
In the interest of browser-compatibility checking, and given limited resources, is it worthwhile to test my HTML 4/CSS 2 web applications and sites with older versions of Firefox, or is it sufficient to test with the current version (v3.6 as at the time of writing)?
If I need to test against older versions, why? What are the things that I need to look out for?
UPDATE 1: This applies to a generally available audience and we can assume the browser usage patterns are the same as for the general public.
As a general rule, test your application in as many different environments as you can. It's never a BAD idea to test it against an older version of a browser.
Of course, given time limits and realistic requirements, you may want to limit the scope of your tests. For example, unless you're creating an application for the government, you usually won't need to test anything below Internet Explorer 6.
As for Firefox, the 2.x release was when it started to become really popular. It's easy to imagine that there are many people out there still on Firefox 2.x. The main thing you need to watch out for is differences with the way CSS is handled. Older browsers may render certain CSS tags differently or just plain don't have support for some of them.
I usually do check in older browsers, and follow this list http://developer.yahoo.com/yui/articles/gbs/ of A grade browsers. Unless it's just a very quick site I test in all A Grade Browsers.
The main reason to check different browsers is to make sure that the different users get the same experience and that your site actually works. Some obvious things are css fixes, javascript / ajax fixes, or things not working, PNG transparencies not working in IE6 and so on.
As said before, you need to know your demographics and what the site is used for. If it's an internal site, or one where only a limited people have access to it, and you know they don't use IE 7 or lower, or the older versions of Firefox, then there is really no need to cross check. But I'd say for the general public websites, stick with A grade browsers and you're pretty good.
If you want to test with a lot of different browsers, this free service might be helpful for you:
http://browsershots.org/
(Adobe had a commercial service in the past, but they shut it down in 2013.)
If a significant fraction of your intended audience use the old versions, yes.
Is this a generally available application, or will it be restricted to one organisation? If the latter, then the corporate policies on browser support will determine this.
First, find out what the browser demographics to your site are like.
That should drive any compatibility testing.
If you find that you have many users with older versions of Firefox, then it would be worthwhile.
You might find out that some other browser you had not considered should be a focus.
Good question!
If your application targets less tech-savvy people, I'd say a basic test against 2 is still mandatory. I've seen plenty of machines still running 2 because of turned off auto-updates and such.
I'm putting together some virtual machines to test different browsers and I'm wondering if there is any compelling reason to be able to test the same version of IE on different versions of Windows. (i.e. IE8 on XP and Vista) I'm mostly talking about testing CSS to make sure it "looks right" across browsers, but if there were major differences in JavaScript I would want to know that too.
Are different versions of IE "generally the same" on different versions of Windows? Thanks!
The time and cost of testing different versions of windows would be better spent in other places. This would be one of the last things I would look at when looking for rendering issues.
I agree with both people who have answered previously, despite the fact that they disagree with one another.
In general, IE will act very largely the same across all versions of windows. However, there can be (and are) some occassional subtle differences. Whether these are important are not is up to you.
For the great majority of websites, I wouldn't bother with it. But for very precise web applications where you're using something like complex javascript, or if you require layout to be correct to the pixel for some reason, then it could be worth it. I'm thinking of cases where people are generating os-type applications in JavaScript where the DOM is really being pushed around, and where exact layout and flawless event-handling is critical.
Yes, I am currently testing something out and have varying results between XP and Vista.
--assuming you already have both platforms.
No, I would stick to testing on the current (IE8) and previous (IE7), unless it is a requirement to support older versions. These browsers should render the same across different versions of windows.
I personally dont bother with IE6, the sooner that is gone, the better
I would think there would be very limited cases where you'll notice a difference in IE between Windows versions. One example where you would is a Google toolbar bug I've seen in IE6 that renders html forms unusable. That bug seems to go away when you upgrade to IE8. But that problem is more Google Toolbar than IE.
Other differences you run into may be security or plug-in related. But in the default IE configurations I don't think you'll see any differences in rendering.