1050703 - [TSF] Cursor doesn't move when input an Enter with IME in Contenteditable = true field

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[dindog]

Attachment: Testcase.html

When there is text content exist, you enter key can't not move the cursor to new line. 
Tested with Chinese IME and Japanese IME.


Testcase attached.


First bad nightly :
https://hg.mozilla.org/mozilla-central/rev/2f198e81ed98

Comment 1

[dindog]

I've checked the hourly today:
Good until:
https://hg.mozilla.org/mozilla-central/rev/25bf2f1664e9
Bad first appear:
https://hg.mozilla.org/mozilla-central/rev/7f81be7db528

Comment 2

[Alice0775 White]

1. Please check to see if it works as expected when setting intl.tsf.enable = false in about:config.
2. Please describe detail of IME (name and version).
3. Please describe detail of steps to reproduce the problem.

Comment 3

[dindog]

Attachment: demo.gif

(In reply to Alice0775 White from comment #2)
> 1. Please check to see if it works as expected when setting intl.tsf.enable
> = false in about:config.
No, that doesn't help.

> 2. Please describe detail of IME (name and version).
I can reproduce that in all IME on my windows 8.1, the Japanese IME is the built-in one, Microsoft IME 2012, I'll check Windows 7 later.

> 3. Please describe detail of steps to reproduce the problem.
First, I maybe put a wrong c-set in the first post, the comment 1's  c-set double checked, should be right.

I've made a GIF for demonstration. You can see I can't change line.

Comment 4

[Alice0775 White]

(In reply to dindog from comment #3)

> (In reply to Alice0775 White from comment #2)
> > 1. Please check to see if it works as expected when setting intl.tsf.enable
> > = false in about:config.
> No, that doesn't help.
> 

Did you restart browser after change the value?

Comment 5

[Alice0775 White]

I can reproduce on Windows8.1 and MS IME 2012. but not reproduce with intl.tsf.enable = false.

Comment 6

[Alice0775 White]

And also reproduce on Windows7 and MS Office IME 2010.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I'll research what occurs. Thank you for the report.

Comment 8

[dindog]

(In reply to Alice0775 White from comment #4)
> (In reply to dindog from comment #3)
> 
> > (In reply to Alice0775 White from comment #2)
> > > 1. Please check to see if it works as expected when setting intl.tsf.enable
> > > = false in about:config.
> > No, that doesn't help.
> > 
> 
> Did you restart browser after change the value?

No, I didn't. My fault. :).

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, the reason is, the end of <p> element doesn't have <br> node. Therefore, in generated plain text, there is no line breaker...

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch

This doesn't depend on IME. This is pure our bug.

[] is caret position:

In this case:

<p>foo bar</p><p>[]<br></p>

The generated flat test is:

"foo bar[]\n"

This is not assumed result of ContentEventHandler because it assumed that all <p> elements have <br> in its end. However, it's not true :-(

Therefore,

1. <p>foo bar</p><p>[]<br></p>
2. <p>foo bar[]</p><p><br></p>

Both case 1 and case 2 are same caret position in generated flat text. This is the root cause of this bug. However, it's difficult to fix this quickly and other platforms don't have similar bugs.

So, we should "hide" this bug in nsTextStore for now.

Currently, FlushPendingActions() sets selection even if it's not necessary. By this, selection is moved to #2 from #1. So, if we don't need to modify the caret position at starting composition, we shouldn't dispatch selection set event. This also cuts redundant cost especially on e10s.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/92d8430977c2

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/92d8430977c2