*SEARCH THE NET:* *CLICK HERE TO GET A FREE CELL FONE!* Meleon User's Guide and Reference Manual Prev Chapter 1. Introduction Next ------------------------------------------------------------------------ User Support The user support offered by the K-meleon project consists mostly of users helping each other, although developers will join in when time permits. The manuals, tutorials and references are written both by developers and users. In open forums, you can get answers to your specific questions by more experienced users. When you have solved your problem, please consider submiting a tutorial, or a clarification for the manual that would have helped you solve your problem quicker. In fact, the manual you are reading was written mostly from users' feedback. Getting Help At the documentation page , we offer a set of shorter tutorials that will help you get started with some small but commonly asked configuration settings. There is also a list of Frequently Asked Questions (with answers). Once you are a bit more acquainted with K-Meleon you should be able to digest the full manual. If none of these documents help you to solve your problem you are very welcome to turn to the K-Meleon forum. *Tip: * The forum is archived and it can pay off to search the old posts for questions similar to yours- instead of posting the same question once more. This will save time, both for you and others. The web forums The K-Meleon web forum is the place where users and developers meet to discuss problems in the current version as well as upcoming features and requests for features in future versions. Before you ask questions at the web forum, grant us all some respect by acting as an intelligent human being. You will look pretty silly if the issue is already mentioned, and solved, in the tutorials or FAQ. ALWAYS check there first. Then, see if you can solve the problem yourself by reading the manual. The manual is intended to include all information about the browser, but you will have to apply the information in the manual to your specific problem. Don't be afraid to experiment with the configuration settings and preferences. When you decide that you cannot solve your problem and must ask others for help, please remember that no one is obliged to help you. Be polite. Take the time to reread what you have written before you send it. Make sure it is clear what you want to achieve, what you have tried, and what goes wrong. If you cannot make yourself understood, or you come out as ignorant or demanding, you are not likely to receive much attention. A very good guide to asking questions at open forums-where other people will help you without any compensation- is the text /How to Ask Questions The Smart Way/ , by Eric S. Raymond. This text will help you to be considerate of others and to express yourself clearly. When you have become a more experienced user we would love to see you as a problem-solver by helping new users. If you attempt to solve hard questions you might have to dig through the manual and other documents, but you will use your full creativity and learn something in the process. If you are not sure that you can give the correct answer you should avoid guess work. Perhaps you can refer the problem to an expert who would be able to answer the question. It would be most useful if you point to information in the manual that could help the questioner find an answer himself. In the beginning it is not easy to answer questions with the use of a reference manual, but after a bit of practice everyone can do it. "Teach a man to fish..." Reporting Bugs If you think you have found something that might be a bug in K-Meleon, please start by taking a big breath and calm down. No one planted evil bugs in the program on purpose. Remember that not everything that acts like a bug is a bug. And not all bugs that affect K-Meleon are K-Meleon bugs. Sometimes it is a user error, sometimes it is an error in another program, and sometimes it really is a bug in K-Meleon. If you had any data losses due to the problem it is sad no matter what the reason. We understand your frustration and wish to help avoid it again. Often we need your help to diagnose the error. When a site is not displaying properly it is normally caused by one of two issues. Either the site is not compliant with current HTML standards or if the page is fully standards compliant the display problem is probably due to a bug, or missing features, in Mozilla. Standards tell a browser how to interpret correctly written web pages. When a page violates the standards there are no guarantees that all browsers will show it the same. Let the web masters know such errors. Before you start a big bug-hunting project try to find out if others have spotted the same behaviour before you. Search the bug tracking system and web board archives, or ask at one of the forums. If others have experienced the same issue as you they will tell you the current state of the problem. Sometimes this can be a hint on how to work around it while waiting for the real fix. The key to understanding the causes of a malfunction is being able to reproduce the faulty behaviour. A fault that happens only once in a blue moon is extremely hard to fix. If your bug is mostly harmless it would be very helpful if you could try to provoke it a bit. Try to reproduce it. Write down the exact procedure to trigger the bug. In case the application crashes you can use Dr.Watson to get an idea of where the problem happened. Never bother with the register dump from a blue screen; it is of no use at all. Search Dr.Watson's log file for the latest appended entry, and make sure it is K-Meleon. Write down what occurred. The comment on the exception is important, not the number. Note the function that has an entry marked with "FAULT". The function names in the Stack Back Trace for the faulting thread are very important too. Unfortunately K-Meleon is often stripped on debug information and symbol tables and thus shows entries like 'nosymobls'. With a reproducible bug, disable the plugins and see if the bug persists or goes away. Disable most other options from the preferences as well. Then reactivate a few options at a time. Can you localize the error? Is it a specific plugin that causes the errors? Even if your bug is not fully reproducible but still happens now and then try to find any common factors when it does happen. What are you doing? How does the program respond? Try to observe as much as possible that can help identify what goes wrong. Writing a useful bug-report that leads to fixed bugs is just as hard, if not harder, than posing questions that others care to answer. A good text to read before writing bug-reports is the text How to Report Bugs Effectively, by Simon Tatham. If you consider his advice while writing your bug-report your bug might get fixed quicker. The Bug Tracking System All bugs discovered and reported by users are kept in the bug tracking system (BTS). Before you report something as a bug, make sure it is truely a K-Meleon bug and that it is not already in the BTS. It is a good idea to discuss the issue with others at the web-forum first. *Note: * Before you can enter your report you need to create an account with the K-Meleon Bug Tracking System. To do this you must pick a name and password as well as entering your e-mail address. When you write your report you should make sure the title explains clearly what the bug is all about. Remember to state what version of K-Meleon, and any other programs involved. Write the report so that there are no doubts what one can do to reproduce the bug, what goes wrong, and what behaviour you expect to see instead. Write down any error messages verbatim. If you fail to express yourself clearly it is not likely that anyone will understand what goes wrong. There are too many bugs around to waste time on ghost hunts. If you feel like being helpful, you could take a look at the BTS and the current set of bugs. Several of the bugs are unconfirmed. Maybe you are the detective to decipher what the bug-report talk about and how one can reproduce the bug. Write a more clear comment in that case. There are sometimes open bugs that actually have been fixed already. Sometimes a new bug appears as a side effect from another bug fix or rewrite. Write a comment on what tests you did to come to the conclusion that the bug is no longer around. ------------------------------------------------------------------------ Prev Home Next Introduction Up Development