Konqueror problems and a SERIOUS commitment

"Gérard Talbot" browserbugs at gtalbot.org
Sun Aug 28 23:55:03 BST 2011


Hello all,

The whole thread started by Zé is very relevant and good.


> 1.) If you are a developer, you can start with fixing some small
> issues. If you do not know how to get started with solving a
> particular problem, then you can ask.

Ok, I ask. Is there a document(s), preferably a tutorial(s) on how to get
started with solving bugs in Konqueror (KHTML rendering engine)? Please
list them all.


> 2.) If you are not a developer, then you can in the least make sure
> your bug report is not a duplicate of another that was previously
> reported.


There ought to be a way to reach people who file bug reports and then to
tell them to choose a meaningful, sensible, helpful words, description and
information in their bug reports. Not enough is done in that area, IMO.

------------

One idea, maybe a bit controversial. Have an unchecked checkbox like this:

[] I have searched for possible duplicates and did not find any.

in the https://bugs.kde.org/enter_bug.cgi?product=konqueror&format=guided

The form should be rejected and bug report should not be created if the
user does not check such checkbox. A message should state then that
KDE/KHTML have limited resources, time, etc.., and there is already a lot
of bug reports and that it is the responsibility of bug reporters to
search for duplicates.

------------

A how-to file a bug report FAQ should be created. Right now, there is

Investigating Konqueror Bugs
http://www.konqueror.org/investigatebug/

which is good but has some incorrect and inaccurate info.


Eg "How to report a bug in KDE" link ( http://bugs.kde.org/Reporting.html
)  leads to a 404 Not Found webpage.

Konqueror FAQ
http://www.konqueror.org/faq/
is clearly OUTdated but it is linked in that Investigating Konqueror Bugs
http://www.konqueror.org/investigatebug/ webpage!

I have filed one bug report with regards to
http://www.konqueror.org/investigatebug/
and it is
Investigating Konqueror Bugs, HTML/CSS problem section should use a
doctype triggering web standards compliant rendering mode
https://bugs.kde.org/show_bug.cgi?id=278123

------------

Bug reporters should be told how to indicate and to verify the rendering
mode of their rendering engine: via View menu/ View document information
Ctrl+I and then look for Rendering mode.

Bug reporters should be told that webpage rendered in strict or standards
rendering mode will get priority over one that is in quirks rendering
mode. A quirks rendering mode is an intentional violation of web standards
and is, in fact, the IE5/IE6 bugward rendering mode. So, bugs found in
quirks rendering mode should not be a priority.

------------

Bug reporters should be told to identify the rendering engine involved
when filing up a bug report: is it KHTML or Webkit rendering engine?

KDE/KHTML developers are not dedicated and should not dedicate their time
on a rendering engine developed elsewhere and not developed/not maintained
by KDE.


> The truth is most of these bug reports are really not
> konqueror bugs, but bugs against components used in konqueror, e.g.
> khtml

The formal request in the
https://bugs.kde.org/enter_bug.cgi?product=konqueror&format=guided
to identify the rendering engine would meet such goal. Right now, there is
no formal request in the
https://bugs.kde.org/enter_bug.cgi?product=konqueror&format=guided
to identify the rendering engine.

------------

New bug report keywords should be made available for QA and bug triagers:

a) clean-report is one. It would orient the developers to fix those bug
reports. A clean-report keyword added to a bug report would mean to the
developers that the problem involved in the bug report is real, valid and
has been clearly and cleanly identified, along with a reduced testcase.

> The most important help any user can provide however is to help
> the developers weed through bug reports and find ones that are truly
> valid bugs.

The clean-report keyword would meet such goal.

b) need-reduction is another: It would orient testcases makers to create a
reduced testcase for the bug report. Once created, the need-reduction
keyword could be removed from the bug report.

Mozilla and webkit use or used to use such kind of keywords.

------------

New components of KHTML should be added: CSS is definitely one; HTML4 and
HTML5 could be 2 other ones.

------------

> The truth is most of these bug reports (...) or simply they cannot be
reproduced

No bug report should be marked NEW if it can not be confirmed and can not
be reproduced.

------------

I believe KDE people and Konqueror lovers should be told that if they
contribute a donation and if they request that such donation be invested
into fixing serious, valid Konqueror bugs, then they can do so. KDE e.V.
should help those who want to contribute a donation so that Konqueror bugs
(serious bugs, severe bugs, crash bugs, hang bugs) gets fixed.

I am a Konqueror supporter and I have contributed to KDE e.V. hoping,
thinking, believing and expecting that my donattion would contribute to
fix serious bugs in Konqueror.

regards, Gérard
-- 
Konqueror Implementation Report of CSS 2.1 test suite (RC6): 9418 testcases
http://www.gtalbot.org/BrowserBugsSection/Konqueror4Bugs/Konq-IR-CSS21TestSuite.html
49 Bugs in Konqueror 4.7
http://www.gtalbot.org/BrowserBugsSection/Konqueror4Bugs/
Contributions to the CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html





More information about the kfm-devel mailing list