keeleysam / tenfourfox

Automatically exported from code.google.com/p/tenfourfox
0 stars 0 forks source link

8-bit/Unicode entities in input boxes get doubled #276

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
* I read everything above and have demonstrated this bug only occurs on
10.4Fx by testing against this official version of Firefox 4/up (not
applicable for startup failure) - SPECIFY VERSION YOU TESTED AGAINST:

Firefox 31.0 on OS X 10.9.3

* Layout bugs MUST be tested against a system WITHOUT hardware
acceleration. Go to Help, Troubleshooting Information to see if your test
system is accelerated. If your test system IS accelerated, you must make
sure it is OFF, OR test on ANOTHER system that isn't. If this is NOT a
layout or display bug, you can skip this step.

* This is a startup crash or failure to start (Y/N): N

* This is a fault of JavaScript acceleration (Y/N): (Use the steps above to
find out. Do NOT report if it is not.) N

* What steps are necessary to reproduce the bug? These must be reasonably
reliable.

If I try to type Korean characters on any text-typable areas (address bar, 
search box, any text box in a page) within a TenFourFox 31.0b1 window, texts 
get garbled in a weird way. 

For example, 안녕하세요 ("Hello" in Korean) should look like this: 
http://bit.ly/1pbUbug

Instead, it looks like this when typed on TFF31: http://bit.ly/1qnG88G

As I type in the text box, the characters I type gets added to the right side 
of the cursor in a strange order. I can get the text I tried to type, but it 
follows by a garbled text that I have to manually delete.

* Describe your processor, computer, operating system and any special
things about your environment.

Powerbook G4 15-inch 1.5Ghz PowerPC G4, Mac OS X 10.5.8

* If this is a startup crash or failure to start, have you tried restarting
with a clean profile or in safe mode? Does this fix the problem? N

* For crashes or startup failure (optional): paste in any information from
Crash Reporter, or if you are able to run 10.4Fx in gdb, paste in the
backtrace. You can often do it like this from within Terminal.app:

cd appname.app/Contents/MacOS
gdb firefox
run
*crash the app
bt full

* Include any useful additional information, steps you have tried, etc.:

I also tested Japanese and Chinese input, which also showed similiar problem. 

Resetting TenFourFox or creating a new profile didn't help. TenFourFox 24 and 
29 (+Firefox 31 on Intel) didn't have this problem.

Thanks for your help!

Original issue reported on code.google.com by bws...@gmail.com on 17 Jun 2014 at 9:57

GoogleCodeExporter commented 9 years ago
Accepting. A similar problem is reported with accented characters, which likely 
has the same root cause. I'm treating this as a blocker.

Original comment by classi...@floodgap.com on 17 Jun 2014 at 1:17

GoogleCodeExporter commented 9 years ago
Cut and paste works: ありがとう

So this is likely something with IME. I suspect bug 965685.

Original comment by classi...@floodgap.com on 18 Jun 2014 at 3:37

GoogleCodeExporter commented 9 years ago
In a debug build, trying to type あ, we get this naughty assertion:

2014-06-17 21:05:59.901 firefox[2512] ****in sendCompositionEvent; type = 2200
2014-06-17 21:05:59.910 firefox[2512] ****in sendTextEvent; string = 
'あ{NSUnderline = 2; NSUnderlineColor = NSCalibratedWhiteColorSpace 0.17 1; }'
2014-06-17 21:05:59.910 firefox[2512]  markRange = 0, 1;  selRange = 1, 0
2014-06-17 21:05:59.910 firefox[2512] ****in underlineAttributeToTextRangeType 
= 2
Assertion failure: mLastData == aTextEvent->theText (The text of a text event 
must be same as previous data attribute value of the latest compositionupdate 
event), at 
/Volumes/BruceDeuce/src/mozilla-31b/dom/events/TextComposition.cpp:160

So this pretty clearly implicates IME.

Original comment by classi...@floodgap.com on 18 Jun 2014 at 4:07

GoogleCodeExporter commented 9 years ago
The old 29 code used an array of CountRanges(aString) + 1. This looks like an 
artifact of how the array was constructed. Adding 1 to CountRanges makes no 
difference. So the problem is something about sendTextEvent:.

Original comment by classi...@floodgap.com on 18 Jun 2014 at 4:45

GoogleCodeExporter commented 9 years ago
We're not setting .data in the WidgetCompositionEvent. This is going to be a 
little tricky.

Original comment by classi...@floodgap.com on 18 Jun 2014 at 4:51

GoogleCodeExporter commented 9 years ago
Rewriting our nsChildView.mm IME code to include analogous changes to 
https://hg.mozilla.org/releases/mozilla-aurora/rev/8d48a0f50b4c seems to fix 
the assertion and text seems to function correctly for (tested) Japanese, 
German and Spanish, so it probably all works.

Original comment by classi...@floodgap.com on 20 Jun 2014 at 3:48

GoogleCodeExporter commented 9 years ago
Korean input came back to normal on 31.0b2.

Original comment by bws...@gmail.com on 21 Jun 2014 at 5:52

GoogleCodeExporter commented 9 years ago
Excellent. Thanks for the report. We will consider this ...

Original comment by classi...@floodgap.com on 21 Jun 2014 at 6:00