Investigating Konqueror Bugs
Here is some information about how to investigate a Konqueror bug, to gather as much information as possible before reporting the bug. Doing this helps the developers a great deal, because they directly know where the problem is, without having to do all the investigation themselves.
Unfortunately due to the large number of bug reports received, and the large amount of time that it takes developers to identify issues, reports which do not include a testcase or are not described in reproduceable steps will get a low priority of fixing.
This page is about bugs in the web browser only. For bugs in the file manager, or about any other KDE application, jump directly to the generic How to report a bug in KDE.
Please always test the latest version available. For browser bugs this means the latest development version, which can be very different from the latest stable release.
Also, always give a quick look at the Konqueror FAQ to see if the bug is a well-known bug, possibly with a known fix or workaround.
The first step is finding out the type of bug this is about. The second step is to follow the instructions for this type of bug (follow the links relating to the type of problem). And the third step is to find out the right package to report the bug to.
Page appears completely empty
This could be a problem at many levels (HTML, HTTP, Javascript...).
First check that you have Javascript activated, some sites use Javascript to do redirections etc.
Use wget
to download the page, and see if konqueror can
view the local page. If yes, then it's an HTTP problem.
Also try changing the user agent (in "Configure Konqueror"), to see if the site
isn't giving different results depending on the browser.
If you can't use wget (https site, etc.), try to view the HTML source from konqueror itself. If it's empty, then it's an HTTP problem, if not then it's an HTML/CSS problem or a Javascript problem.
Page appears as plain text (I see the HTML source)
This is very probably an HTTP problem, see the HTTP bug section.
Authentication doesn't work, or isn't remembered
This is very probably an HTTP problem, see the HTTP bug section.Rendering bugs
If something doesn't appear as it should (not the right position in the page, not the right font, etc.), see the HTML/CSS problem section.
Some (Javascript) animation or menu doesn't work
After checking that you have activated Javascript (in "Configure Konqueror"), go to the Javascript problem section.
Konqueror crashes
The most useful information you can provide in that case is a
backtrace, but you need to compile KDE yourself (preferrably with
--enable-debug
) so the backtrace is useful, or to use
development packages. Official binary packages are "stripped", so
they don't contain any useful information for a backtrace. Simply
paste the backtrace from DrKonqi, into the bugreport.
Very important: a backtrace is good, but it's not enough. You must also describe on which site it happened, and which steps one should follow to reproduce the crash.
HTTPS sites don't work
First try other HTTPS sites. If the problem happens only on one, then try activating different ciphers in the SSL control module, some sites don't work well with SSLv3, some need TLS, etc. If the problem happens on all the https sites you try, then it could be an installation problem.
A common case of problems (such as "the protocol https died unexpectedly") is if you don't have openssl at all (install it!) or when your binary packages were built with a certain version of openssl (for instance 0.9.5a) and you are using openssl 0.9.6. Those two versions are binary incompatible, so you have to use the same version as the one your packager used.
If this still doesn't help, follow the instructions for HTTP-related problems, to get some debug output out of kio_http before reporting the bug.
Anything else
If the tips on this page don't seem related to your problem, jump to the next step, finding the right package.
HTML/CSS problem
Your bug is related to HTML and/or CSS. You need to know a bit HTML and follow these steps to build a test case:
- Save the relevant page or frame on your disk.
- Load the page from your disk and see if the problem is still there.
- Only if it's necessary to reproduce the bug: save framesets, images etc.
- Throw out anything that has nothing to do with the bug, i.e. delete some stuff, reload to check if the problem is still there, delete more stuff. Do this until you found the exact cause of the problem. The HTML file should not have more than 20 lines at the end.
- The important part is: the page should be as short as possible to be able to still reproduce the bug. The shorter it is, the sooner it will get fixed!
- The HTML does not have to be valid, however it is still recommended
to use validator.w3.org (note
that you can upload files there, they don't have to be online)
to check the basic structure of your document.
Here's an example of a minimal test case that's valid HTML:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head><title>konqi test</title></head> <body> <p>insert the problematic HTML here</p> </body> </html>
- Submit a bug report to the KDE bug system with the test case in the bug report, and the description of the problem. You should add "testcase" to the description of the bug so it's easier for the developers to find test cases.
HTTP problem
Here's how to debug an HTTP problem, if you have compiled KDE from sources (otherwise there is no debug output to look into, since binary packages disable it).
The goal here is to generate and access debug output messages, so first we have to make sure where it will end up.
- If you start X using "startx", and if you distribution doesn't
automatically redirect output messages into a file in your
home directory (as Caldera does), then you should restart X using
startx 2>&1 | tee ~/xsession.log
, and the debug output will go into ~/xsession.log. - If you start X in 'runlevel 5', i.e. using xdm, gdm or kdm, then the debug output automatically goes into ~/.xsession-errors on most distributions (RedHat, Mandriva, Debian...) and goes into ~/.X.err on SuSE.
Now we can generate the debug output:
- Run
kdebugdialog
, locate the areas 7103 and 7113, and activate them (check the checkbox). Then press Ok. - Restart KDE (or simply kill any kio_http process)
- Open konqueror onto the webpage you're interested in
- Look for the debug output at the location previously determined
Now, actually digging info out of the debug output requires to know the HTTP protocol. If you don't, try to reduce the debug output to what starts with kio_http, and send it as part of the bug report.
Javascript problem
A very useful piece of information (besides a reduced test case that shows the bug) is the debug output from konqueror, since any javascript error is printed there (assuming you're not using RPMs with disabled debug output).
Simply start "konqueror" from a terminal, and open the web page in question. The lines startings with "JS:" are those printed by the javascript interpreter. If you see any errors, report them as part of the bug report.
Once you have gathered the required information, find the right package to which the bug should be reported to :
Package | Problem |
---|---|
konqueror | Any bug that is not inside the "view", but part of the framework, e.g. the toolbar |
khtml | Rendering/layouting bugs, crashes that don't go a away when you visit a html page and have Javascript and Java disabled |
kjs | Any dynamic Javascript thingie not working or crashing. Might be a bug in khtml, but as it's difficult to judge for the user this package line is fine |
kjava | Java related problems |
kssl | https (SSL) related problems |
kio_http | Problems with the http communication itself. |
kcookiejar | Cookie related problems |
Now go to the KDE bug system to send in a bug report. Thanks!
[ Edit ]