Bug 422950 - Konqueror KHTML text input not shown, button not disarmed until window focus change
Summary: Konqueror KHTML text input not shown, button not disarmed until window focus ...
Status: RESOLVED MOVED
Alias: None
Product: frameworks-khtml
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.66.0
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Martin Sandsmark
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-14 07:15 UTC by Taketo Kabe
Modified: 2020-11-15 02:26 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
half-heated attempt to make typed text appear immediately (713 bytes, text/plain)
2020-06-28 14:46 UTC, Taketo Kabe
Details
Quarter-hearted implementation to make text appear on type, button unarms (1.86 KB, text/plain)
2020-07-19 10:30 UTC, Taketo Kabe
Details
Patch to render QLineEdit text caret cursor visible in decoreated KLineEdit (1.78 KB, text/plain)
2020-07-19 10:36 UTC, Taketo Kabe
Details
Patch to render QLineEdit text caret cursor visible in decorated KLineEdit (2.93 KB, patch)
2020-07-23 13:22 UTC, Taketo Kabe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Taketo Kabe 2020-06-14 07:15:04 UTC
SUMMARY
When Konqueror is used with KHTML engine,
- Text input in textbox is not rendered immediately.
- Pressed button does not get disarmed.
When changing the window focus to other, the text in textbox is rendered and
button get disarmed, triggerring any actions with it.


STEPS TO REPRODUCE
1. Launch Konqueror with KHTML engine. Input methods probably should be off.
2. Browse a page with a text box, such as http://www.google.com/ .
3. Type text into the text box. It isn't visible. Text cursor caret is also missing.
4. Switch focus to another window. The typed text will be rendered.

OBSERVED RESULT
Input text is not visible. It is rendered after window focus change.

EXPECTED RESULT
Input text should be visible immediately.

SOFTWARE/OS VERSIONS
Linux: CentOS 8.1/EPEL 8
KDE Plasma Version: 5.59
KDE Frameworks Version: 5.59
Qt Version: 5.11

khtml version: 5.59, 5.60, 5.65, 5.66
(I could not test out newer ones due to distribution's compatibility)

ADDITIONAL INFORMATION

A simple HTML to show the bug:

<FORM>
<INPUT id=1 type="text" size=20 />
<INPUT type="button" value="append x" onclick="getElementById(1).value+='x'" />
</FORM>

When pressing the button, button doesn't get disarmed;
changing the window focus disarms the button and the textbox will have "x" appended.


Similar bug was reported in year 2017

Konqueror does not display any text typed in text fields/areas nor changes in... 
https://bugs.kde.org/show_bug.cgi?id=380134
KHTML Forms: text not visible, email attachments not sent 
https://bugs.kde.org/show_bug.cgi?id=369682

but was not addressed.
Comment 1 Taketo Kabe 2020-06-28 14:46:09 UTC
Created attachment 129743 [details]
half-heated attempt to make typed text appear immediately

This patch will make the text appear immediately on type.
The textbox caret cursor is still missing. I don't know why the caret doesn't appear.

The patched line is a quarter-heated job of what had been done in 
#if QT_VERSION < QT_VERSION_CHECK(5, 0, 0)
region below.
Comment 2 Taketo Kabe 2020-07-19 10:30:38 UTC
Created attachment 130237 [details]
Quarter-hearted implementation to make text appear on type, button unarms

A revised patch of above for KHTML.
Text input in textfield appear immediately, and button unarms on onClick.

The text caret cursor seems invisible, but you can barly see it when
typing a text and pressing left arrow button; the text caret cursor is
rendered in background color, so it is nearly invisible.
Fixing this needs a patch for QLineEdit, which follows.
Comment 3 Taketo Kabe 2020-07-19 10:36:05 UTC
Created attachment 130238 [details]
Patch to render QLineEdit text caret cursor visible in decoreated KLineEdit

The text caret cursor in QLineEdit is temporary rendered by
QPainter->setCompositionMode in QPainter::RasterOp_NotDestination,
but this seems to not work nicely in decorated (CSS "border-style" set)
KLineEdit widget. It makes text caret cursor rendered in background color.

This patch makes it uses QPainter::RasterOp_SourceOrNotDestination,
which makes text caret cursor rendered visible.

WARNING: this patch is for Qt5 qtbase; not for khtml. I'll try reporting this to Qt.
Comment 4 Taketo Kabe 2020-07-23 13:22:50 UTC
Created attachment 130335 [details]
Patch to render QLineEdit text caret cursor visible in decorated KLineEdit

Warning: this patch is for qt5-qtbase, not for khtml.

After experimenting for various color schemes, QLineEdit (QTextEdit) needed major overhaul
of drawDursor().
The attached patch will finally render the text caret cursor in fair colors, testcase HTML below.

<HTML>
<BODY style="background:#DDDDDD" >
<FORM action="./">
<INPUT id=1 type="TEXT" size=20 /> undecorated<br />
<INPUT id=2 type="TEXT" size=20 style="border-style:solid; border-color:#FF0000; background: inherit; color:#000000" /> bg:inherit, color:black<br />
<INPUT id=3 type="TEXT" size=20 style="border-style:solid; border-width:1;" /> border only<br />
<INPUT id=4 type="TEXT" size=20 style="border-style:solid; border-color:#FF0000; background: #777777; color:#000000" /> bg:777, color:000<br />
<INPUT id=5 type="TEXT" size=20 style="border-style:solid; border-color:#0000FF; background: #111111; color:#EEEEEE;" /> bg:111, color:eee<br />
<INPUT id=6 type="TEXT" size=20 style="border-style:solid; border-color:#00FFFF; background: #dddddd; color:#00EEEE;" /> bg:ddd, color:0ee<br />
<INPUT id=7 type="TEXT" size=20 style="border-style:solid; border-color:#FFFF00; background: #222222; color:#EEEE00;" /> bg:222, color:ee0<br />
<INPUT id=8 type="TEXT" size=20 style="border-style:solid; border-color:#777777; background: inherit; color:#880088;" /> bg:inh, color:808<br />
</FORM>
</BODY>
</HTML>

(I still cannot be able to report this in KHTML, since the site seems to disable cursor blink timer)
Comment 5 Christoph Feck 2020-11-15 02:26:25 UTC
Superseeded by bug 429126.