312838 - When using Microsoft Input Method Editor(IME), intermittent failure of active text selection highlight to be displayed in single line text boxes

Status: VERIFIED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Paul Blay]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

I am identifying this as a Firefox problem because 
a) The appearance of the Microsoft Input Method Editor (IME) is different in
Firefox than in other programs.
b) I have not encountered this glitch outside of Firefox.

Background: When using the IME to enter Japanese[1] text the 'active text'[2] is
highlighted by an underline mark.  In Firefox this is a thin red solid line
slightly underneath the text.  In other programs it is a dotted black line that
is level with the base of the text.  This visual feedback is essential to
knowing whether any text is 'active' and if so which characters.

In the case of Firefox it intermittently (not very often) fails to display this
line.  I suspect that the line is 'under' the bottom edge of the text box and
thus hidden.

Adverse Effect:
Without the visual feedback it is easy to accidentally press the 'choose
transformed text' key when no text is 'active'.  As that key is [ENTER] /
[RETURN] by default this can easily result in the accidental premature
submission of a form.

[1] or other languages such as Chinese that require an initial 'english letter'
input that is later transformed into characters of the required language.

[2] Text that will be transformed to the target language when the relevant key
is pressed.

Reproducible: Sometimes

Steps to Reproduce:
1. Click to place the text cursor in a normal single line text box (such as the
one on the link attached).
2. Start the IME.
3. Type some text.
Actual Results:  
Text is displayed, but without indication of the 'active text' selection.

Expected Results:  
Text displayed with a highlight effect (Firefox : thin red underline, Other :
dotted black underline).

I have images taken of 
1. Normal appearance of 'active text selection' highlight in Firefox.
2. 'active text selection' in Firefox with highlight missing.
3. Normal appearance of 'active text selection' highlight in Internet Explorer.
I do not think these add much other than proof of the glitches existance.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

*** This bug has been marked as a duplicate of 170951 ***

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Ah, Sorry I misread the report.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Did you report the problem that is missing underline?
If so, please attach the screenshot.

# I cannot reproduce this problem.

Comment 4

[Paul Blay]

Attachment: IME 'active word' highlight. The last three characters should be underlined.

Comment 5

[Paul Blay]

Attachment: IME 'active word' highlight. This is how it should look in Firefox.

Comment 6

[Paul Blay]

Attachment: IME 'active word' highlight in Internet Explorer (for comparison). Note line is closer to base of text.

Comment 7

[Paul Blay]

Just to emphasise this is a very intermittent glitch.
I estimate it occurs as little as one in 100 times or less, however when it
turns up on a textbox it is consistently repeatable on that textbox until the
page is reloaded.

Comment 8

[Paul Blay]

I should have checked this before but ...

In the 'good' screenshot there is a gap of four pixels between the interior base
line of the textbox and the text.  There is a one pixel gap between the base and
the underline.
In the 'bad' screen shot there is a three pixel gap between the interior base
line  of the textbox and the text.
In the screen shot from IE there is a three pixel gap between base line and
text, but the underline is directly (one pixel) underneath the text (two pixels
gap from base of textbox to underline).

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Attachment: screenshots

Umm... We have a underline drawable space.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Attachment: screenshots2

Oh, the top of text downed to 1px.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

This problem is similar to Bug 173051 and Bug 287624.
Saito-san has fixed Bug 167001, but isn't it enough?

Comment 12

[Paul Blay]

(In reply to comment #11)
> This problem is similar to Bug 173051 and Bug 287624.
> Saito-san has fixed Bug 167001, but isn't it enough?

I encountered this in Firefox 1.5 Beta 2.  As it is very intermittent it may not
be very suprising that nobody else has reported it.

I have downloaded the latest nightly build (Deer Park Alpha 2) and will report
back when / if I catch it happening again (and in what circumstances).

I'm a user rather than a developer so I can't really do more than that.

Comment 13

[Hideo Saito]

> Saito-san has fixed Bug 167001, but isn't it enough?

Although I have not checked this condition yet, a problem still remains although
Bug 167001 was fixed. I think that this problem was influenced by a
fix(attachment 92074 [details] [diff] [review]) for Bug 156943. Please refer to Bug 212302 and posted
patch(attachment 155983 [details]) and comment
https://bugzilla.mozilla.org/show_bug.cgi?id=212302#c20. I think that other
methods should be considered in order not to change a baseline.

Comment 14

[Hideo Saito]

> Please refer to Bug 212302 and postedpatch(attachment 155983 [details] [edit])

Please refer to Bug 212302 and posted patch(attachment 159983 [details] [diff] [review] [edit])

Comment 15

[Paul Blay]

Addition & Correction:

I have discovered how to _consistently_ reproduce this bug on my system with 
the page I linked to.
I am now using Deer Park Alpha 2 (version 1.61a1).

Steps to Reproduce:
1. Click to place the text cursor in a normal single line text box (such as the
one on the link attached).
2. Start the IME.
3. Type some Japanese text (the underline will be visible as normal) 
4. Type some English text (as soon as you enter the first character you should see the text go down one pixel).

furthermore

5. Delete the English text (as soon as the last English character is deleted the 
Japanese text goes back up one pixel).

Sorry I failed to notice this point before (I very rarely have both English and 
Japanese text on the same line in that page).  Possibly this makes 
http://www.csse.monash.edu.au/~jwb/wwwnewword.html a 'broken page' but I fail 
to see anything unusual about the TABLE and INPUT tags there.

Comment 16

[Paul Blay]

Same bug occurs on the text box at http://dictionary.goo.ne.jp/

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Attachment: testcase

Sorry, for the delay. I can reproduce in case1.

Please test this testcase. Don't delete default character and use IME in the editors. On case1, I can reproduce the problem with "MS ゴシック"(MS Gothic).
But on case2, I cannot reproduce it. Because the editor height is enough for rendering by "MS ゴシック"(MS Gothic).

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Attachment: testcase2

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Attachment: screenshot of testcase2

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Attachment: screenshot of testcase2 with patch

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

I confirmed this bug is fixed by attachment 159983 [details] [diff] [review].

Comment 22

[Hideo Saito]

It seems that the testcase is fixed by Bug 212302 fixed. Please reopen if it is not right.

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

-> v.