Closed Bug 1312649 Opened 3 years ago Closed 3 years ago

[Mac][Sierra] Vietnamese Telex won't start composition at typing something except if Firefox is built with OS X 10.12 SDK

Categories

(Core :: Widget: Cocoa, defect, P3, major)

49 Branch
x86_64
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox51 --- fixed
firefox52 --- fixed

People

(Reporter: thanghx, Assigned: masayuki)

References

Details

(Keywords: inputmethod, Whiteboard: vietnamese input type MacOS Sierra)

Attachments

(4 files)

Attached video Screen recorder for bug
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20161019084923

Steps to reproduce:

On MacOS Sierra 10.12+
1. Add vietnamese input method if hasn't (System Preferences/Keyboard/(Tab) Input Sources/Add Vietnamese telex)
2. Select Telex vietnamese input method.
3. Open Firefox
4.1 In any textbox input controls (Address bar, Search bar, or website text input controls) type following characters in sequence 'g', 'o', 'x' now the text should be 'gõ' (in vietnamese it mean 'typing'). Press delete key
4.2 Clear previous text. now type 'a', 'p', 'p', 'l', 'e' text should be 'apple'. Press delete key.
4.3 In address bar, type 'a', 'p', 'p', 'l'. It should suggest 'apple.com' with 'e.com' highlighted in blue. Press enter.


Actual results:

4.1: Whole text 'gõ' is deleted
4.2: 'le' is deleted
4.3: Firefox shows result of searching for 'appl'


Expected results:

4.1: Only 'õ' should be deleted.
4.2: Only 'e' should be deleted.
4.3: Firefox should open apple.com website.
Severity: normal → major
Keywords: inputmethod
OS: Unspecified → Mac OS X
Priority: -- → P3
Hardware: Unspecified → x86_64
Whiteboard: vietnamese input type MacOS Sierra
Component: Untriaged → Widget: Cocoa
Product: Firefox → Core
Could you test on the latest Nightly from https://nightly.mozilla.org/?  It have some fixes.
Flags: needinfo?(thanghx)
Attached video bug_ffnightly52.0a1.mov
(In reply to Makoto Kato [:m_kato] from comment #1)
> Could you test on the latest Nightly from https://nightly.mozilla.org/?  It
> have some fixes.

Bug still there in Nightly 52.0a1
Sorry for the delay to reply. I tested with the latest Nightly.

(In reply to thanghx from comment #0)
> 4.1 In any textbox input controls (Address bar, Search bar, or website text
> input controls) type following characters in sequence 'g', 'o', 'x' now the
> text should be 'gõ' (in vietnamese it mean 'typing'). Press delete key
> 4.1: Whole text 'gõ' is deleted

Reproduced.

> 4.2 Clear previous text. now type 'a', 'p', 'p', 'l', 'e' text should be
> 'apple'. Press delete key.
> 4.2: 'le' is deleted

I cannot reproduce this. All of 'Apple' is deleted.

> 4.3 In address bar, type 'a', 'p', 'p', 'l'. It should suggest 'apple.com'
> with 'e.com' highlighted in blue. Press enter.
> 4.3: Firefox shows result of searching for 'appl'

I cannot reproduce this. Looks like that it works as you expected.
Flags: needinfo?(thanghx)
Let's take this bug as treating only the #1 which is confirmed.

thanghx: If you will see #2 and/or #3 after fixing this bug, please file new bugs for each of them because we cannot manage multiple problems with one bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Typing vietnamese in firefox for Mac problem → [Mac] Delete key causes removing whose word which is inputted with Vietnamese Telex
Summary: [Mac] Delete key causes removing whose word which is inputted with Vietnamese Telex → [Mac] Delete key causes removing whole of the word which is inputted with Vietnamese Telex
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #4)
> Sorry for the delay to reply. I tested with the latest Nightly.
> 
> (In reply to thanghx from comment #0)
> > 4.1 In any textbox input controls (Address bar, Search bar, or website text
> > input controls) type following characters in sequence 'g', 'o', 'x' now the
> > text should be 'gõ' (in vietnamese it mean 'typing'). Press delete key
> > 4.1: Whole text 'gõ' is deleted
> 
> Reproduced.
> 
> > 4.2 Clear previous text. now type 'a', 'p', 'p', 'l', 'e' text should be
> > 'apple'. Press delete key.
> > 4.2: 'le' is deleted
> 
> I cannot reproduce this. All of 'Apple' is deleted.

Are you keeping Vietnamese telex? Please watch my attached screen record

> 
> > 4.3 In address bar, type 'a', 'p', 'p', 'l'. It should suggest 'apple.com'
> > with 'e.com' highlighted in blue. Press enter.
> > 4.3: Firefox shows result of searching for 'appl'
> 
> I cannot reproduce this. Looks like that it works as you expected.
Again, this bug only happen in VN-telex mode.
@Masayuki Nakano:
"Summary: [Mac] Delete key causes removing whose word which is inputted with Vietnamese Telex → [Mac] Delete key causes removing whole of the word which is inputted with Vietnamese Telex"

I don't think this only relate to Delete key. This is about abnormal behavior of typing Vietnamese Telex in FF for Mac (10.12).
This bug does happen With OS X < 10.11 (El Capitan)
I realized odd behavior of Telex.

This is what Telex sent us on Nighty at pressing "g":
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 TextInputHandler::HandleKeyDownEvent, calling interpretKeyEvents
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=0, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=0, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=0, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=0, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=0, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 IMEInputHandler::HasMarkedText, mMarkedRange={ location=9223372036854775807, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 IMEInputHandler::GetValidAttributesForMarkedText
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 IMEInputHandler::GetValidAttributesForMarkedText
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 IMEInputHandler::GetValidAttributesForMarkedText
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 IMEInputHandler::GetValidAttributesForMarkedText
> [Main Thread]: I/TextInputHandlerWidgets 129490a50 TextInputHandler::InsertText, aAttrString="g", aReplacementRange=7fff55505c28 { location=9223372036854775807, length=0 }, IsIMEComposing()=FALSE, IgnoreIMEComposition()=FALSE, keyevent=11e402c00, keydownHandled=FALSE, keypressDispatched=FALSE, causedOtherKeyEvents=FALSE

And this is on Debug build:
> [Main Thread]: I/TextInputHandlerWidgets 19eece6a0 TISInputSourceWrapper::InitKeyEvent, shift=off, ctrl=off, alt=off, meta=off
> [Main Thread]: I/TextInputHandlerWidgets 118684160 TextInputHandler::HandleKeyDownEvent, calling interpretKeyEvents
> [Main Thread]: I/TextInputHandlerWidgets 118684160 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=0, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 118684160 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=0, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 118684160 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=0, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 118684160 IMEInputHandler::HasMarkedText, mMarkedRange={ location=9223372036854775807, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 118684160 IMEInputHandler::GetValidAttributesForMarkedText
> [Main Thread]: I/TextInputHandlerWidgets 118684160 IMEInputHandler::GetValidAttributesForMarkedText
> [Main Thread]: I/TextInputHandlerWidgets 118684160 IMEInputHandler::GetValidAttributesForMarkedText
> [Main Thread]: I/TextInputHandlerWidgets 118684160 IMEInputHandler::GetValidAttributesForMarkedText
> [Main Thread]: I/TextInputHandlerWidgets 118684160 IMEInputHandler::GetValidAttributesForMarkedText
> [Main Thread]: I/TextInputHandlerWidgets 118684160 IMEInputHandler::SetMarkedText, aAttrString="g", aSelectedRange={ location=1, length=0 }, aReplacementRange=7fff54584520 { location=9223372036854775807, length=0 }, Destroyed()=FALSE, IgnoreIMEComposition()=FALSE, IsIMEComposing()=FALSE, mMarkedRange={ location=9223372036854775807, length=0 }

So, on Nightly, Telex does not start composition but on debug build, it starts composition. So, at pressing Delete key with the STR of #1, the condition is really different.

NOTE: the latter behavior is same as other applications.

thanghx: Perhaps, this might depend on internal state of Telex. I'll continue to investigate deeper. Note that the summary doesn't need to describe all symptoms but need to describe specific symptom or the technical cause.
Oh, what a bug... When I build Nightly on Sierra with MacOSX10.12.sdk, Telex works fine. However, when I build Nightly on El Capitan with MacOSX10.11.sdk, Telex won't work fine.

I guess something necessary new method isn't implemented without MacOSX10.12.sdk but I don't see any differences of NSTextInputClient protocol...

mstange: Any idea?
Flags: needinfo?(mstange)
Sounds like a bug in 10.12 to me. Can you file a bug at http://bugreport.apple.com/ ?

We've had cases in the past that required us to switch to a newer SDK (bug 1045128). This might be such a case.
Flags: needinfo?(mstange)
(In reply to Markus Stange [:mstange] from comment #11)
> Sounds like a bug in 10.12 to me. Can you file a bug at
> http://bugreport.apple.com/ ?
> 
> We've had cases in the past that required us to switch to a newer SDK (bug
> 1045128). This might be such a case.

But how can I tell them that bugs while other apps still works well (Chrome, Mail, Notes...etc)
(In reply to Markus Stange [:mstange] from comment #11)
> Sounds like a bug in 10.12 to me. Can you file a bug at
> http://bugreport.apple.com/ ?
> 
> We've had cases in the past that required us to switch to a newer SDK (bug
> 1045128). This might be such a case.
Yes, I think so (about newer SDK) but how can I tell them that's their bug while other apps still works well (Chrome, Mail, Notes...etc)
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #10)
> Oh, what a bug... When I build Nightly on Sierra with MacOSX10.12.sdk, Telex
> works fine. However, when I build Nightly on El Capitan with
> MacOSX10.11.sdk, Telex won't work fine.
> 
> I guess something necessary new method isn't implemented without
> MacOSX10.12.sdk but I don't see any differences of NSTextInputClient
> protocol...
> 
> mstange: Any idea?

Thanks for your work, Masayuki. Could you send me a link to your new build on Sierra with MacOSX10.12.sdk?
(In reply to Markus Stange [:mstange] from comment #11)
> Sounds like a bug in 10.12 to me. Can you file a bug at
> http://bugreport.apple.com/ ?

Thank you, filed as 29058175 (I don't find direct link for the report).

(In reply to thanghx from comment #12)
> But how can I tell them that bugs while other apps still works well (Chrome,
> Mail, Notes...etc)

Most applications don't implement NSTextInputClient protocol by themselves. Instead, such applications use native text input handler (NSTextView or something), therefore, they won't hit such bug.

Although, I'm not sure how Chromium implement that, Firefox implements the protocol with an abstract object, NSView. Therefore, Firefox sometimes hits such low level bugs.

(In reply to thanghx from comment #14)
> (In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #10)
> Thanks for your work, Masayuki. Could you send me a link to your new build
> on Sierra with MacOSX10.12.sdk?

Unfortunately, I don't have enough space, bandwidth and time for providing my original build. If you want to build Firefox on Sierra, you can do it easy. You need to install Xcode, install other tools with one line script introduced in <https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Mac_OS_X_Prerequisites#One-Line_Setup_(Try_This_First!)>, get the source code <https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code/Mercurial#mozilla-release_(release_tree)>, then, run |./mach build| in the top directory of the source code.
And note that when I google "Telex Sierra", I see some posts which asked the reason and workaround of not working Telex on some applications.
Summary: [Mac] Delete key causes removing whole of the word which is inputted with Vietnamese Telex → [Mac][Sierra] Vietnamese Telex won't start composition at typing something except if Firefox is built with OS X 10.12 SDK
Fortunately, I find the cause of different behavior of Telex from Chrome. That is, we don't return any styles when validAttributesForMarkedText: of NSTextInputClient is called. The patch for part.2 tries to fix this difference.  However, when I try to fix the backspace key behavior, I found two bugs of our key event handling.  They should be fixed before hiding by part.2.  So, the patch, part.1, fixes them.
Although, even with those fix, Telex behaves odd.

At first time, when you type "o", only "o" is underlined. However, after that, any characters are underlined. For example, "g", "o", "x", "Backspace", "Backspace" becomes focused editor empty again. Then, at typing "g" again, "g" is underlined. But such inconsistent behavior is bug of Telex, I think. I'll keep talking about this with Apple.
Comment on attachment 8808084 [details]
Bug 1312649 part.1 TextInputHandler::InsertText() should dispatch composition events instead of keypress events when it replaces a range which is different from current selection

https://reviewboard.mozilla.org/r/91010/#review91124
Attachment #8808084 - Flags: review?(m_kato) → review+
Comment on attachment 8808085 [details]
Bug 1312649 part.2 IMEInputHandler::GetVaildAttributesForMarkedText() should return non-empty array

https://reviewboard.mozilla.org/r/91012/#review91128

::: widget/cocoa/TextInputHandler.mm:3621
(Diff revision 1)
> -  //                                 NSTextInputReplacementRangeAttributeName,
> -  //                                 nil];
> -  // empty array; we don't support any attributes right now
> -  return [NSArray array];
> +  //     this may be called a lot.  Note that Chromium does so.
> +  return [NSArray arrayWithObjects:NSUnderlineStyleAttributeName,
> +                                   NSUnderlineColorAttributeName,
> +                                   NSMarkedClauseSegmentAttributeName,
> +                                   NSTextInputReplacementRangeAttributeName,
> +                                   nil];

Yes, I think that we shouldn't create NSArray per call.

Although We should use like the following code, it should handle it by new bug.

```
static NSArray* validAttr;
if (valid) {
  validAttr = @[NSUnderlineStyleAttributeName, ...];
  CFRetain(validAttri);
}
return validAttr;
```
Attachment #8808085 - Flags: review?(m_kato) → review+
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/6bfd79a3ab98
part.1 TextInputHandler::InsertText() should dispatch composition events instead of keypress events when it replaces a range which is different from current selection r=m_kato
https://hg.mozilla.org/integration/autoland/rev/05f8aed1d9c5
part.2 IMEInputHandler::GetVaildAttributesForMarkedText() should return non-empty array r=m_kato
https://hg.mozilla.org/mozilla-central/rev/6bfd79a3ab98
https://hg.mozilla.org/mozilla-central/rev/05f8aed1d9c5
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Odd... The 2nd patch won't work as expected in released Nightly build. So, even with the latest Nightly, I don't see Telex starts composition at typing "o" when I type "gox" immediately after rebooting macOS. (I have no idea what's different from tryserver build...)

Fortunately, the 1st patch fixed the bug at handling insertText: of NSTextInputClient. So, actually, the behavior becomes nicer, though.

thanghx: Could you test new Nightly build and file new bugs if you still see some problems?
Flags: needinfo?(thanghx)
Tested on (still) version 52.0a1:
- Delete key works as expected

But I got "text composition not start" phenomenon too (I dont know how to reproduce it) which leads to following bugs (happen when typing in vn telex mode in address bar/search bar only):
- Text suggestion not work as expected on address bar (see: Item 4.3)
- Space key not work as expected: need to hit space-key twice to get a space (see my screen record)
Confirm that "text suggestion" and "twice space-key" phenomenon happens on web page text controls either if "text composition" not start already
Thank you for your test. At least I tested on Safari, Telex never starts composition. Do you see same symptom on Safari? Or only on Firefox? If the latter, we should fix each case in another bug.
Flags: needinfo?(thanghx)
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #32)
> Thank you for your test. At least I tested on Safari, Telex never starts
> composition. Do you see same symptom on Safari? Or only on Firefox? If the
> latter, we should fix each case in another bug.

Yes, It seems that from Sierra text composition does not happen on other applications anymore
Comment on attachment 8808084 [details]
Bug 1312649 part.1 TextInputHandler::InsertText() should dispatch composition events instead of keypress events when it replaces a range which is different from current selection

Approval Request Comment
[Feature/regressing bug #]: New regression of macOS Sierra due to changing its IME behavior (part.1 is actually our bug, part.2 improves compatibility with Google Chrome).
[User impact if declined]: Some Vietnamese users cannot use their IME, Telex, comfortable. Additionally, uplifting this helps and reduces the risk of bug 1317906 which should be fixed in release. Although, even with these fix, there are some issues but I'm talking with Apple about that.
[Describe test coverage new/current, TreeHerder]: Landed on m-c at almost end of 52 cycle.
[Risks and why]: I think low, but some IME on Mac behaves odd (including Apple's IMEs like Telex). So, it *might* affect to some of them.  However, according to my experiments, non-Japanese IME's regressions are not reported until released. Therefore, uplifting IME patches makes improvement faster.
[String/UUID change made/needed]: Nothing.
Attachment #8808084 - Flags: approval-mozilla-release?
Attachment #8808084 - Flags: approval-mozilla-beta?
Comment on attachment 8808084 [details]
Bug 1312649 part.1 TextInputHandler::InsertText() should dispatch composition events instead of keypress events when it replaces a range which is different from current selection

Wow, sorry, I missed to cancel the request for release, it's pretty risky for uplifting to release.
Attachment #8808084 - Flags: approval-mozilla-release?
Comment on attachment 8808085 [details]
Bug 1312649 part.2 IMEInputHandler::GetVaildAttributesForMarkedText() should return non-empty array

Approval Request Comment: See previous comment.
Attachment #8808085 - Flags: approval-mozilla-beta?
Hi :masayuki,
It seems to me that there are still some issues here like comment #30 (My test results in nightly also showed that text suggestion doesn't work as expected on address bar). Can we let the fix of this bug and bug 1310565 ride the train 52?
Flags: needinfo?(masayuki)
(In reply to Gerry Chang [:gchang] from comment #37)
> Hi :masayuki,
> It seems to me that there are still some issues here like comment #30 (My
> test results in nightly also showed that text suggestion doesn't work as
> expected on address bar). Can we let the fix of this bug and bug 1310565
> ride the train 52?

This bug and bug 1310565 were fixed at 52. However, others are not sure. I don't see any problem as you mentioned in comment 30. Could you file bugs for each problem? And when you record video to explain the "steps to reproduce" and the symptom, could you include "Keyboard Viewer" of macOS? Pressing key is highlighted in Keyboard Viewer, therefore, I could understand what's the difference of your operation.

Note that if we can uplift follow up fixes depend on the risk of the patches. If it's too risky for uplift, we cannot do that. Otherwise, release drivers may allow to uplift them because of not minor problems.
Flags: needinfo?(masayuki)
1. The issue I addressed is exactly the same as Item 4.3 in comment #0. 
2. I try to understand if the issues are fixed (it seems not based on my simple test) and risks so that I can judge if I will approve this to uplift or not.

Hi Florin,
I might need your help to find someone in your team to verify if this is fixed as expected and if any other new issues are found.
Flags: needinfo?(florin.mezei)
Hi,

I tested this issue on iMac OS X 10.12 with FF Nightly 53.0a1 (2016-11-18) (64-bit) and FF Developer Edition 52.0a2 (2016-11-17) I have set input sources Vietnamese Telex and here are the results:

What works as expected:

4.1 works as expected (Only 'õ' is deleted)
4.2 works as expected ( Only 'e' is deleted)

What doesn't work as expected:

4.3 If I type 'a', 'p', 'p', in URL bar It should suggest 'apple.com' with 'le.com' highlighted in blue and then press enter Firefox deletes the highlighted part and after I press second time enter it shows result of searching for 'app'.

Also another issue is the space key fictionality. If I type something in the URL bar and then press space key it doesn't work only on the second attempt. 

Note:

Having the same environment (Vietnamese Telex) on Chrome all works as expected, on Safari the issue from 4.3 is reproducible. 
I tested this issues setting the input sources to U.S. and all works as expected. 

Masayuki can you please take a look and tell me if I need to log a new bug for this?
Flags: needinfo?(florin.mezei) → needinfo?(masayuki)
(In reply to ovidiu boca[:Ovidiu] from comment #40)
> Hi,
> 
> I tested this issue on iMac OS X 10.12 with FF Nightly 53.0a1 (2016-11-18)
> (64-bit) and FF Developer Edition 52.0a2 (2016-11-17) I have set input
> sources Vietnamese Telex and here are the results:
> 
> What works as expected:
> 
> 4.1 works as expected (Only 'õ' is deleted)
> 4.2 works as expected ( Only 'e' is deleted)

Yes.

> What doesn't work as expected:
> 
> 4.3 If I type 'a', 'p', 'p', in URL bar It should suggest 'apple.com' with
> 'le.com' highlighted in blue and then press enter Firefox deletes the
> highlighted part and after I press second time enter it shows result of
> searching for 'app'.

I didn't touch this issue because I don't understand about this and really different issue than 4.1 and 4.2 (I'd like to treat one issue per one bug). So, both same result as en-US keyboard layout or really different bug could be.

> Also another issue is the space key fictionality. If I type something in the
> URL bar and then press space key it doesn't work only on the second attempt. 

Hmm, Telex's behavior (I meant about communication between Telex and application is unclear and unstable) is what I'm asking to Apple.

But by your this comment, I see another bug, I'll file a new bug for it.

> Note:
> 
> Having the same environment (Vietnamese Telex) on Chrome all works as
> expected, on Safari the issue from 4.3 is reproducible. 

Wow, really?

> I tested this issues setting the input sources to U.S. and all works as
> expected. 

Thanks, that's the most important. I fixed the Backspace issue and made Gecko claim to work as Chrome to Telex. So, it's okay if address bar behavior is not broken than current release.

Sorry, I should've made it clear in whiteboard or somewhere.
Flags: needinfo?(masayuki)
Hi :Ovidiu,
Please open another bug for tracking item 4.3.
Flags: needinfo?(ovidiu.boca)
It seems that not inserting " " with space key will be fixed by bug 1310565. Could you test it with the latest Nightly? The fix was already landed only in Nightly. But if you still see the issue, please file a new bug for it.
Thanks Garry for your suggestion. 

For the issue tracked in item 4.3 I filled https://bugzilla.mozilla.org/show_bug.cgi?id=1319018
Flags: needinfo?(ovidiu.boca)
Comment on attachment 8808084 [details]
Bug 1312649 part.1 TextInputHandler::InsertText() should dispatch composition events instead of keypress events when it replaces a range which is different from current selection

Fix an issue related to Vietnamese Telex in Sierra. Beta51+. Should be in 51 beta 3.
Attachment #8808084 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8808085 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
needs rebasing for beta 

erging widget/cocoa/TextInputHandler.mm
warning: conflicts while merging widget/cocoa/TextInputHandler.mm! (edit, then use 'hg resolve --mark')
abort: unresolved conflicts, can't continue
(use 'hg resolve' and 'hg graft --continue')
Flags: needinfo?(masayuki)
Did you merge the patch for bug 1310565 before the patch for this?
Flags: needinfo?(masayuki) → needinfo?(cbook)
FYI: I confirmed that after applying the patch for bug 1310565, I can apply both patches without any error. (I used |hg import|)
Flags: needinfo?(cbook)
FYI: I fixed bug 1341960 in Nightly last week. It might improve some behavior of Vietnamese Telex if you still not see marked text (underlined text) during inputting text. (If you see marked text as we expected, the fix won't help you.)
You need to log in before you can comment on or make changes to this bug.