Bug 280226 - Rendering errors with KLineEdits
Summary: Rendering errors with KLineEdits
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml forms (show other bugs)
Version: 4.6.4
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords: testcase
Depends on:
Blocks:
 
Reported: 2011-08-16 22:08 UTC by Rolf Eike Beer
Modified: 2012-05-09 10:25 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.3


Attachments
screenshot of the errors (8.80 KB, image/jpeg)
2011-08-17 06:15 UTC, Rolf Eike Beer
Details
simplified testcase (382 bytes, text/html)
2011-08-17 14:27 UTC, Andrea Iacovitti
Details
possible patch (622 bytes, patch)
2011-08-17 15:55 UTC, Andrea Iacovitti
Details
another testcase including normal, readonly and disabled input text (402 bytes, text/html)
2011-08-26 21:52 UTC, Andrea Iacovitti
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rolf Eike Beer 2011-08-16 22:08:18 UTC
Version:           4.6.4 (using KDE 4.6.4) 
OS:                Linux

The following HTML fragment will have a damaged drawing of the line edits which will go away when you hover the broken place with the mouse. For me it looks like the clear button was originally drawn at that place and then it was removed because the input is disabled.

The third input box has the border of the box disorted around the clear button as if the clear button is an image with a non-transparent background.

If you can't reproduce the errors please ping me and I'll attach a screenshot. I've seen this on at least 3 totally different computers for several KDE SC versions.

Reproducible: Always

Steps to Reproduce:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Disabled button test</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
</head>
<body>
<table>
<tr><th colspan="2">With table around</th></tr>
<tr>
<td><label for="n_name">Name:</label></td>
<td><input id="n_name" type="text" name="n_name" size="60" value="Entry
that needs some space" readonly="true" /></td>
</tr>
</table>
<input id="n_name2" type="text" name="n_name2" size="60" value="Another
entry that needs some space" readonly="true" />
<br/>
<input id="n_name3" type="text" name="n_name3" size="60" value="foobar" />
</body>
</html>


Expected Results:  
Proper rendering ;)
Comment 1 Andrea Iacovitti 2011-08-17 00:17:57 UTC
(In reply to comment #0)
> The third input box has the border of the box disorted around the clear button
> as if the clear button is an image with a non-transparent background.
^^^
This issue has an already open report (#230024).

Cannot reproduce here the "damaged drawing of the line edits".
Comment 2 Rolf Eike Beer 2011-08-17 06:15:59 UTC
Created attachment 62887 [details]
screenshot of the errors
Comment 3 Andrea Iacovitti 2011-08-17 14:27:42 UTC
Created attachment 62899 [details]
simplified testcase

The problem happens on readonly input text pre-filled with some value.
As you described the clear button was originally drawn and then removed because the input is disabled and this results in a damaged drawing of the line edit.
Comment 4 Rolf Eike Beer 2011-08-17 15:35:25 UTC
> The problem happens on readonly input text pre-filled with some value.
> As you described the clear button was originally drawn and then removed
> because the input is disabled and this results in a damaged drawing of the
> line edit.

If you look while the page is drawn you can actually see the clear button
appear for a short moment.
Comment 5 Andrea Iacovitti 2011-08-17 15:55:39 UTC
Created attachment 62905 [details]
possible patch
Comment 6 Andrea Iacovitti 2011-08-26 21:52:09 UTC
Created attachment 63164 [details]
another testcase including normal, readonly and disabled input text
Comment 7 Andrea Iacovitti 2011-09-17 09:09:06 UTC
Git commit 07d20a558da67fb9f849e2b20c52cf275ea01794 by Andrea Iacovitti.
Committed on 17/09/2011 at 10:12.
Pushed by aiacovitti into branch 'KDE/4.7'.

-Do not set WA_OpaquePaintEvent attribute for line edit clearButton
 (should fix the not transparent background bug)
-Optimize a bit the code to enable/disable it

BUG: 230024
CCBUG: 280226
FIXED-IN: 4.7.2

M  +1    -0    kdeui/widgets/klineedit.cpp
M  +5    -2    khtml/khtmlview.cpp
M  +8    -7    khtml/rendering/render_form.cpp

http://commits.kde.org/kdelibs/07d20a558da67fb9f849e2b20c52cf275ea01794
Comment 8 Andrea Iacovitti 2011-09-20 20:05:40 UTC
It seems the "damaged drawing of the line edit" is caused by a bug in the proxy style used in input text form elements (#280445).
To reproduce load the testcase at comment #6 and hit reload button.
Comment 9 Andrea Iacovitti 2012-04-20 06:20:36 UTC
Git commit dee2801c0a86fec1c642da9710b17b0a7bec3ecd by Andrea Iacovitti.
Committed on 20/04/2012 at 08:18.
Pushed by aiacovitti into branch 'KDE/4.8'.

Fix rendering of text input elements having padding by removing the use
of cached parent's proxy style, that end up to return a wrong content rect
size, and using ad-hoc style() function instead. Actually only KLineEdit
inherits KdeUiProxyStyle (since kde 4.5) so the behavior of our internal
proxy is unchanged for the other form elements (i.e m_proxy was always 0 for them).

Also the crash reported in #197270 is no longer reproducible after this change,
likely it has been fixed elsewhere...
Related: bug 280445
FIXED-IN: 4.8.3

M  +7    -11   khtml/rendering/render_form.cpp

http://commits.kde.org/kdelibs/dee2801c0a86fec1c642da9710b17b0a7bec3ecd
Comment 10 Ivan Čukić 2012-05-09 10:25:32 UTC
Git commit 658759cb7c436af133b770bc50c99219dff10814 by Ivan Čukić, on behalf of Andrea Iacovitti.
Committed on 20/04/2012 at 08:18.
Pushed by ivan into branch 'ivan/plasma-active-patches'.

Fix rendering of text input elements having padding by removing the use
of cached parent's proxy style, that end up to return a wrong content rect
size, and using ad-hoc style() function instead. Actually only KLineEdit
inherits KdeUiProxyStyle (since kde 4.5) so the behavior of our internal
proxy is unchanged for the other form elements (i.e m_proxy was always 0 for them).

Also the crash reported in #197270 is no longer reproducible after this change,
likely it has been fixed elsewhere...
Related: bug 280445
FIXED-IN: 4.8.3

M  +7    -11   khtml/rendering/render_form.cpp

http://commits.kde.org/kdelibs/658759cb7c436af133b770bc50c99219dff10814