Compatibility/Guide
Working on Web Compatibility Issues
As said on Web Compatibility page:
A person should be able to use the Web from which ever device and browser they are using.
There are many ways we, Web users, can help make the Web a better place:
- Collect information about well-known sites in your own country.
- Report the issues in a useful way.
- Analyze the Web sites so that the bugs contain useful information.
- Contact Web sites owners (or developers) for fixing Web compatibility issues.
The work and the effort of the community is key to the success of the open Web. These efforts have to be considered in the constraints of the business requirements of each contacted Web site. We are not here to blame, we are here to make the Web open to anyone. The Web compatibility effort is driven by two projects mobile Web compatibility and desktop Web compatibility.
Collecting Information And Surveys
Once a mobile device has been introduced in a new country, some Web sites will exhibit issues of Web compatibility. Every country has popular Web sites which are related to their local market (for example well known press and magazines sites).
Steps to follow
- Create a page with a list of top Web sites. See for example Brazil, India or Germany
- Start small, grow it little by little
- For each Web site, test the site with Firefox OS, Firefox Android (and Opera Mobile, IEMobile, Chrome Mobile, Android, etc.)
- Note differences and open individual bugs for each individual issue (see below)
Reporting a Web compatibility issue
What?
- Enter the Web site URI
- You have not been able to use it with your Web browsers of choice
- Check on other browsers. Are there any differences making the site unusable.
You can help!
This guide is focused on Mozilla browsers but you can also help other browser vendors. If you have an issue with Opera (Bug Wizard), Chrome (Bug), Safari (Bug) or Internet Explorer (Bug).
PS: We try to avoid to fix Web sites which are working badly everywhere. We focus first our energy on Web sites which are broken in one browser and not the others.
Requirements
You will need a Mozilla bugzilla account. If not create a new account.
Steps to follow
The person (volunteer or Mozilla engineer) will need to know which steps you have followed to reach the issue. The more details you give, the better chance the issue will be properly addressed. If, for example, one must log in to see the issue, it is important to say so.
- Create a new bug in Bugzilla
- Describe the steps you have been doing for reaching the point where you have an issue: Example of steps
- Describe what is happening
- Describe what you were expecting
- Give information about your device and your browser
- (Bonus) Test in one or more browsers to understand the differences: Example of tests in different browsers
Someone might ask further questions in the bug report to better understand the issue.
Do not forget: Be nice. It is our collective effort.
Analyzing for Web Compatibility Issues
There are many ways of analyzing a Web site for Web Compatibility issues. We could write an entire book with the types of issues and techniques used to find them.
Mozilla Bugzilla Process for Analysis
You might want help analyzing Mobile Web Compatibility bugs. A bug which has the status NEW or ASSIGNED are basically the same.
- When analyzing the bug, take it (and change the bug to ASSIGNED).
- Once you've discovered the type of issue affecting the site:
- document in a comment
- flag it with a whiteboard keyword for example [serversniff] if it's related to server side user agent detection.
- If you do not plan to work further on the bug, such as contacting the Web site, Unassign yourself
You may use some tools and techniques for investigating bugs.
Finding The Right Contact on a Web site
For solving the issues, we often need to find the right person on the Web site. It is often the hardest part of the job, but it's where you can really make a difference. Some Web sites are written in a language that you are mastering. Some Web sites are in country where we do not have much context on how to contact the right person. You can help. The open Web is the work of everyone. Here is a concrete example. If you have more tips, share them here.
There is more than one strategy for finding a person related to a Web compatibility issue. Here are a few:
- Does the company have a developer relations department?
- Is there a support email address or Web form on the Web site?
- Is there an email address for the Communications department?
- Is there an email address for the Technical department?
- If the company has an organigram of their management, search for people who are CTO, Marketing, or Communications related, then check online if you can find them either on Twitter or Linkedin. But, be careful. If the person is obviously only using the account for personal stuff, do not bother them.
- Does the company have a Twitter account?
- Does the company have a Github, Bitbucket or Google code account?
- As a last resort, you may try through their Press relations address which is usually open.
- Call a phone number of the company, though you may be bounced around.
- You might want to check the WHOIS record for the domain name. In some rare cases, it is possible to find useful information about the owner of the site.
Before contacting, read the next section.
Negotiating with the Web site for fixing a Web compatibility issue
First of all, this is a negotiation process. People you will try to contact have their own set of constraints and that might be difficult for them to understand, fix the issue. So be nice.
- Never ever be aggressive with the persons you are trying to reach out. We want a better Web, not an angry Web ;).
- Never assume you are contacting the right person.
- Do not harass people with a lot of emails (even if they are nice to you). A good rule of thumb is to wait one week between contacts. Then a month for the third contact. If nothing has happened during the 5 weeks, give up.
- Never share publicly the emails or names of people in the bug report if they have not decided to reveal themselves. Sometimes people will be willing to help fix a Web site without necessarily telling their management. Exposing them would make their work more difficult.
- Invite people to participate to the bugzilla themselves.
- If someone doesn't want to open a bugzilla account but is willing to share his/her comments in the bug report, help them to publish it (but only if they agree).
There is no perfect email for contacting Web site, but if you think you are not necessarilyy contacting the right person it helps to write shorter emails. We created some templates in different languages. They are very simple, straight to the point and asking for better contact information. It is just an example. Some countries require more formalism, etc. Adjust depending on the local culture in your own language.
On twitter, it could be straightforward. For example
@example Hi, would you know who I should contact for Web site issues? See https://bugzilla.mozilla.org/show_bug.cgi?id=<issue_number>
Bugzilla Conventions for Web Compatibility Issues
Status
This is a short explanation of the bug status in Web Compatibility Area.
- UNCONFIRMED: This bug has been opened, probably through Mobile Web Compat form
- NEW: The bug has been confirmed and probably analyzed. Whiteboard flags are added. It's free for everyone to work on it.
- ASSIGN: A person has been assigned on the bug. It has been taken.
- FIXED: A site was fixed in response to a request made by volunteers through Mozilla.
- WORKSFORME: If the problem is no longer there but we haven't asked for any fixes (yet)
- INVALID: If a bug is not a valid Tech Evangelism bug in the first place
whiteboard keywords for categorizing the issues
We are using a set of keywords in the whiteboard field to help us figuring out priorities, languages, etc.
- [contactready]: Once the Web site has been analyzed for Web compatibility issues. Someone can take the bug and contact the Web site for achieving a resolution. List of Web sites to contact
- [notcontactready]: Sometimes a bug has a dependency or is in the process of being further investigated, hence it is not ready for being formally contacted.
- [sitewait]: Once the Web site has been contacted for Web compatibility issues. This helps to not have two separate persons contacting the same Web site. Leave also a comment with the date when you contacted the site. list of contacted Web sites
- [country-ISOCODE]: Some websites are dedicated to a specific country. For example, a French Web site can be classified as [country-fr], a japanese Web site as [country-jp], for international Web sites you can use [country-all]
- [uaoverride]: When the current bug is about the UA override list added on to Firefox for Android or Firefox OS
- [clientsniff]: When the sniffing is happening on the client-side such as HTML or JS
- [serversniff]: When the sniffing is happening on the server-side such as HTTP redirection and/or different content being served on the same domain
- [lib-foo]: When related to a specific JS lib being used. Example [lib-yui] [lib-jquery] [lib-mootools]
- [tier1]: When the issue is about a site not giving the nicest experience that some other browsers get. For example, getting the low-end mobile version instead of the shiny touch version.
- [webkitcss]: An interoperability issue created by WebKit CSS: missing -moz- and/or prefixless equivalent.
Dependencies bugs
- bug 739832 for dependencies on Webkit CSS prefixes for Firefox Android.