User Support

The user support offered by the kmeleon project is largely based on users helping each other. Developers partake in helping users when time permits.

There are manuals, tutorials and references written both by developers and users. There are also open forums, like web-boards and mailing lists, where you can get answers to your specific questions by more experienced users. When you have solved your problem, please consider to submit a tutorial, or a clarification for the manual, that would have helped you solve your problem quicker. That is to some extent how the current help pages have been formed.

Getting Help

The best help should help yourself to self-help.

At the documentation page, we offer a set of shorter tutorials that will help you get started with some small, but commonly asked for, configuration tasks. There is also a list of Frequently Asked Questions (with answers). Once you are a bit more aqcuainted with K-Meleon you should be able to digest the full manual. If you still cannot solve the problem you are very welcome to turn to the K-Meleon forum.

Tip: The forum is archived and it can therefore pay off to search among 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 upcomming features and feature requests for future versions.

Before you run off to 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. After that, see if you can solve the problem yourself from reading the manual. It is intended to include all information about the browser. Not all answers, but all information. You will have to apply the information on your problem to reach the answer.

When you decide that you cannot solve the problem yourself but have to 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 text about 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. Have you never thought of who will answer your questions and why, this is great food for thoughts.

When you have become a more experienced user we would love to see you as a trouble-solver, helping new users. If you go for the real hard questions you might have to dig through the manual, use your full creativity, and learn something in the process yourself. In case you are not sure that you can give the correct answer you should avoid guess working. Perhaps you at least know what expert would be able to answer the question, and can help that way.

It would be most useful if you point out what information in the manual could help the questioner find an answer himself. In the beginning it is not easy to answer your own 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 by will.

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, somtimes 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 as sad no matter what the reason is. We understand your frustration and wish to help avoid that it ever happens 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. It is the standards that tells how a browser should interpret correctly written web pages. When a page violates the standards there are no guarantess that all browsers will show it the same. Let the web masters know such errors. If the page is fully standards compliant the display problem is probably due to a bug, or missing features, in Mozilla.

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 hints on how to work around it while waiting for the real fix.

The key to understand what causes a malfunciton is being able to reproduce the faulty behaviour. Faults that only happens once in a blue moon are often 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 reproduced it. Write down the exact procedure to trigger the bug if you find out how.

In case of application crashes you can use Dr.Watson to easily 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 bug you can reproduce, disable the plugins and see if the bug persits or goes away. Disbale most other options from the preference configure as well. Activate a few things at a time. Can you localize the error? Is it a specific plugin that causes the errors?

Even if your bug is not fully reproducable but still happens now and then try to find any common factors for the times 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 bugs being fixed 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. Take some of those thoughts in consideration while writing your bug-report, and the bug might actually get fixed quicker.

The Bug Tracking System

All bugs discovered and reported by users are kept in the bug tracking system. 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 it is easy to see already from the title what the bug is all about. Remeber to state what version of K-Meleon, and any other programs involved, that you use. Write the report in a way such that there are no doubts what one can do to reproduce the bug, what goes wrong for you, and what behaviour you expect to see instead. Write down any error messages verbatim. Would you fail to express yourself clearly it is not likely that anyone can understand what goes wrong for you. 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 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.