Bug 39578 – IME: no underline is shown when entering Japanese preedit text in an input box on QtWebKit

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Qt

[Ryuichi KUBUKI]

[How to Reproduce]

1. Run browser.exe of Qt 4.7 beta on Windows XP (Japanese version or locale).
2. Open google.com
3. Enable Japanese IME
4. Enter some text on the search word box

[Expected Result]

A dashed underline is shown under the entered preedit text

[Actual Result]

Nothing is shown under the entered preedit text


This issue could be reproduced with Qt 4.7 Beta and its stock browser.exe, and on Qt 4.6.1 + WebKit r59752.
It makes QtWebKit almost unusable on Japanese platforms.

[Ryuichi KUBUKI]

This part of QtWebKit API, QWebPagePrivate::inputMethodEvent, seems related, so I set the component as QtWebKit. Please change it if my assumption is off.

if (!ev->commitString().isEmpty())
        editor->confirmComposition(ev->commitString());
    else if (!ev->preeditString().isEmpty()) {
        QString preedit = ev->preeditString();
        editor->setComposition(preedit, underlines, preedit.length(), 0);
    }

[Samuel Nevala]

Tested with Symbian 3rd edition phone (12-pad).

On regular Qt application when typing dashed underline shown for pre-edit text and underline show with predictive mode.

With Anomaly and google.com loaded when typing dashed underline is not shown for pre-edit text and no underline for predictive mode.

[Tasuku Suzuki]

Created attachment 57758 [details]
proposed patch

underline is drawn but too low. The patch is a workaround that adds 2px margin under underline.

[Ryuichi KUBUKI]

(In reply to comment #3)
> Created an attachment (id=57758) [details]
> proposed patch
> 
> underline is drawn but too low. The patch is a workaround that adds 2px margin under underline.

Tested the patch against WebKit r60645 + Qt 4.6.1.
On Windows Server 2003 + MS-IME, no underline is shown.

[Kenneth Rohde Christiansen]

Is this supposed to be up for review?

[Tasuku Suzuki]

(In reply to comment #5)
> Is this supposed to be up for review?

As the patch doesn't work for Ryuichi, I marked it as obsolete.

[Joel Parks]

Is this bug still valid?  Ryuichi Kubuki, could you retest and report?

[Ryuichi KUBUKI]

(In reply to comment #7)
> Is this bug still valid?  Ryuichi Kubuki, could you retest and report?

It's still valid wrt the latest Qt SDK 1.1.2 (http://get.qt.nokia.com/qtsdk/Qt_SDK_Win_online_v1_1_2_en.exe). Unfortunately I can't test the latest WebKit revision.

[Tasuku Suzuki]

Created attachment 99267 [details]
proposed patch

[Benjamin Poulain]

Comment on attachment 99267 [details]
proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=99267&action=review

You do not explain how this patch solve the original problem. I wonder if we can solve the bug without the save()/restore().

The change looks sane but I am not convinced that is the best solution. Saving and restoring state is not cheap. In the general usage of RenderObject::drawLineForBoxSide(), the state varies actually very little between calls so the rendering is effective even on OpenGL graphic system.

> Source/WebCore/ChangeLog:13
> +        No new tests. (OOPS!)
> +

This should not be in the changelog.

[Benjamin Poulain]

I remove [Qt] from the title since the patch is cross port and might be of interest for others.

[Tasuku Suzuki]

(In reply to comment #10)
> (From update of attachment 99267 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=99267&action=review
> 
> You do not explain how this patch solve the original problem. I wonder if we can solve the bug without the save()/restore().
> 
> The change looks sane but I am not convinced that is the best solution. Saving and restoring state is not cheap. In the general usage of RenderObject::drawLineForBoxSide(), the state varies actually very little between calls so the rendering is effective even on OpenGL graphic system.

The patch doesn't seem to solve the original problem directly. But when I commented out a line below, underline was drawn correctly. This is why I added save()/restore() in the method.
// graphicsContext->setStrokeStyle(NoStroke);

Do you think to reset the stroke style manually would be better?

[Benjamin Poulain]

Comment on attachment 99267 [details]
proposed patch

(In reply to comment #12)
> The patch doesn't seem to solve the original problem directly.

You should fully understand the problem in order to write a solution. The patch might solve part of the problem, or hide it.

This also makes it impossible for us to review. You should explain what was going on that was causing the problem, and why this patch is the correct solution.

Please investigate what is going on here, and improve the changelog. If you can reproduce the problem on Safari or Chromium, you should also add a pixel test.

[Michael Levin]

Apologies about reviving an old bug, but this issue still affects Webkit browsers on Mac (latest nightly of Webkit, Safari, and Chrome). You can reproduce with the following HTML snippet:

<input type="text" style="border:none;font:16px arial,sans-serif">

To reproduce, type any text with Japanese IME in Hiragana or Katakana mode into the input field. When the underlined romaji is automatically converted into Japanese characters, the font shifts down and the underline is no longer visible.

Is there any chance that someone can look into this again?

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.