Konqueror • Contribute • Investigating bugs

Investigating Konqueror Bugs

Here is some information about how to investigate a Konqueror bug, to gather as much useful 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.

Due to the large number of bug reports received and to the large amount of time that it takes developers to identify issues, bug reports which do not include a reduced test case will get a low priority of fixing or may not be confirmed. Reports which are not described in reproduceable steps may not be confirmed.

If you are reporting a bug report on Konqueror, then it is objectively in your best interests to follow the guidelines and recommendations listed in this document.

This page is about bugs in the web browser only. For bugs in the file manager, or about any other KDE application, choose the product in the guided format of the KDE Bug Tracking System.

General considerations when creating a bug report on Konqueror

Creating a bug report is just a first step of a long process which may or may not end with a bug fix. The Quality Assurance bug triaging people first need to gather all the information relevant to the issue or problem, then reproduce the issue or problem and then search for possible duplicates in the bug tracking system. These steps take considerable amount of time to volunteers doing bug triaging.

Always test with the latest stable available version. Otherwise, you may be reporting a bug that has already been fixed in the newest stable version of Konqueror. The newest stable version of KDE is regularly announced in the KDE.org announcements section; links to binary packages from your distribution are also often provided. Example given: KDE 4.8.0 version release page has a section listing binary packages for KDE 4.8.0 for the Gentoo, Kubuntu and openSuse distributions. Ideally, you should be setting up your software packages manager to download and install Konqueror.

Be factual as much as possible and remain formal when describing the bug. Rants, advocacy, negativity, anger and impatience are not helpful to anyone and will not help fix your bug: in fact, these can only make developers avoid working on the bug.

Be clear and try to bring useful, helpful information to the developers when describing, explaining the bug. Bug reporters should always try to bring useful, meaningful information into their bug report. Example given: if Konqueror crashes when visiting a particular page and you suspect that such crash is related to Flash player, then the most useful information you can bring in the bug report is to identify the domain name part of the webpage address (URL) into the bug summary and to state that you are using the Flash player from Adobe and to indicate what is the Flash player plugin version you are using in the bug description. Ideally, the bug summary should state such information. Bad is: "Bug summary: Konqueror crashes" is not useful, helpful information. In fact, it duplicates the information already contained in the bug form. Good is: "Crash at www.example.org: Flash player related"

The single most important piece of information of a bug report is the bug summary A good bug summary will identify the issue, will help find such bug report when checking for possible duplicates. Searching for possible duplicated bug reports is time-consuming: help everyone (Quality Assurance Bug triaging people and KDE developers) by editing a meaningful bug summary. Bad is: "Konqueror crashes". Better is: "Crash at www.example.org: Flash player related".

Additional reading: The most important field in a bug report: the summary

Only one issue per bug report. If a single webpage has several issues or problems or suspected bugs, then you should create separate bug reports for each issues that you see. This helps isolate issues, reduce complexity and developers' time and efforts.

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:
Settings/Configure Konqueror.../Java & Javascript section/Javascript tab/Enable Javascript globally checkbox is checked.
Make sure that Konqueror allows redirections:
Settings/Configure Konqueror.../Web Browsing/Miscellaneous/Allow automatic delayed reloading/redirection;
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:
View/View Document Source Ctrl+U.
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/layout 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 (preferably 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 indicate the webpage address (URL) where the crash occured 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 reduced test case:

  1. Save the relevant page or frame on your disk.
  2. Load the page from your disk and see if the problem is still there.
  3. Only if it's necessary to reproduce the bug: save framesets, images etc.
  4. Throw out everything 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.
  5. The important part is: the test page should be as short as possible to be able to still reproduce the bug. The shorter it is, the sooner it can get fixed!
  6. The HTML code should be properly structured and using valid markup code: 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//EN" "http://www.w3.org/TR/html4/strict.dtd">

<html>

 <head>

  <title>Reduced test case for [Bug number and bug summary]</title>

 </head>

 <body>

  <p>insert the problematic HTML here</p>

 </body>

</html>

  7. Submit a bug report to the KDE bug system with the test case in the bug report, and the description of the problem. You can add "testcase" into the keywords list of the bug so that it's easier for the developers to find bug reports with test cases.

Creating a reduced test case is universally important for all browser vendors and several software manufacturers which have bug tracking system. If you are the web author having a web site and you are reporting a bug affecting one of your webpage, then you are the best person in a position to create a reduced test case.

Additional reading:

Identify Konqueror rendering engine and webpage rendering mode

In the bug description, you can identify the rendering engine (KHTML or WebKit) that your Konqueror software is using. Do:
Settings/Configure Konqueror.../General section/Default web browser engine

Webpages can be rendered in 3 different rendering modes: Strict, Almost standards and Quirks. The best and most web interoperable rendering mode for all browsers is Strict (usually called web standards compliant rendering mode). In the bug description, you can identify the rendering mode used to display the webpage on which you are reporting a bug. Do:
View/View Document Information Ctrl+I/ Rendering mode:

HTTP or FTP problem

Here's how to debug an HTTP or FTP problem, if you have compiled KDE from sources, or on distributions which do not disable debug output completely.

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 your distribution doesn't automatically redirect output messages into a file in your home directory, 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 using login manager such as kdm, xdm, or gdm, then the debug output automatically goes into ~/.xsession-errors on most distributions (RedHat, Mandriva, Debian, Kubuntu...) and goes into ~/.X.err on SuSE.

Now we can generate the debug output:

  • Run kdebugdialog.
  • Make sure the checkbox "Disable all debug output" is unchecked (KDE >= 4.4).
  • HTTP: type 'http' and check all the checkboxes (in particular 7103 and 7113).
  • FTP: type 'ftp' and check all checkboxes.
  • Press Ok.
  • Restart KDE (or simply kill any kio_http or kio_ftp 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 protocol. If you don't, try to reduce the debug output to what starts with kio_http/kio_ftp, 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.

For experienced users: alternatively, you can enable the reporting of javascript errors with
Settings/Configure Konqueror.../Java & Javascript section/Javascript tab/Debugging section/Enable debugger and Report Errors checkboxes checked

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/layout bugs, crashes that don't go 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!

Additional reading:

[ Edit ]

Global navigation links