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

RESOLVED FIXED in mozilla34

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: dindog, Assigned: masayuki)

Tracking

(Depends on: 1 bug, {inputmethod, regression})

Trunk
mozilla34
x86_64
Windows 7
inputmethod, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
Created attachment 8469919 [details]
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
(Reporter)

Comment 1

4 years ago
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

4 years ago
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.
Flags: needinfo?(dindog)
(Reporter)

Comment 3

4 years ago
Created attachment 8470627 [details]
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.
Flags: needinfo?(dindog)

Comment 4

4 years ago
(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?
Flags: needinfo?(dindog)

Comment 5

4 years ago
I can reproduce on Windows8.1 and MS IME 2012. but not reproduce with intl.tsf.enable = false.
Blocks: 1037328
Component: Editor → Widget: Win32
Keywords: regression
Summary: Cursor doesn't move when input an Enter with IME in Contenteditable = true field → [TSF] Cursor doesn't move when input an Enter with IME in Contenteditable = true field

Comment 6

4 years ago
And also reproduce on Windows7 and MS Office IME 2010.

Updated

4 years ago
Flags: needinfo?(dindog)
I'll research what occurs. Thank you for the report.
Assignee: nobody → masayuki
Keywords: inputmethod
Version: unspecified → Trunk
(Reporter)

Comment 8

4 years ago
(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. :).
Hmm, the reason is, the end of <p> element doesn't have <br> node. Therefore, in generated plain text, there is no line breaker...
Created attachment 8470770 [details] [diff] [review]
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.
Attachment #8470770 - Flags: review?(VYV03354)
Status: NEW → ASSIGNED
Attachment #8470770 - Flags: review?(VYV03354) → review+
https://hg.mozilla.org/mozilla-central/rev/92d8430977c2
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Depends on: 1057192
Depends on: 1058446
You need to log in before you can comment on or make changes to this bug.