BugAThon Bangkok Found on Mac OS X and Linux ( Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4) Gecko/2008031317 Firefox/3.0b4 ) Works fine with Windows. Currently, in Firefox 3 Beta (Mac OS X and Linux), textfield/textarea allow input that starts with non-base Thai character (like upper/lower vowels, or some special symbols), this behavior will lead at least two anomalies: Bug 421275 – Thai above and below vowels display incorrectly in URL bar Bug 157534 – Edit->Find in Page found substring in Thai display cell, but it shouldn't be (more strange behavior of this Bug 157534 is that, since Firefox/Gecko will not highlight single lone non-base character -- user will see that Find bar report that it found a search string, but he will not see any highlighted text as expected). We propose that textfield/textarea should not allow user to enter any non-base Thai character at the start of string. i.e. do sequence checking. Bug 421275 and Bug 157534 will be closed, all CCs will be moved here.

Obviously, this can be solved by fixing Bug 353776.

As Bug 353776 has been fixed, this bug is supposed to be gone. Could somebody verify it?

This problem is solved in Firefox 4.0b8pre with Ubuntu 10.10 .

Artit confirmed it still exists on Mac. Is this something that we're using OS libraries to determine?

But I think it should not allow "า" "ะ" "ำ" "ๆ" "ฯ" too because no thai words are start with this vowel. (this has solved in body and search bar but it's still not solved in address bar and find bar.)

(In reply to comment #5) > But I think it should not allow "า" "ะ" "ำ" "ๆ" "ฯ" too because no thai words > are start with this vowel. (this has solved in body and search bar but it's > still not solved in address bar and find bar.) This part is not yet fixed on Ubuntu, and still applies to Mac/Win.

(In reply to comment #4) > Artit confirmed it still exists on Mac. Is this something that we're using OS > libraries to determine? Ah, yes. The fix for Bug 353776 is on GTK+ only. We need more work for Mac.

(In reply to comment #5) > But I think it should not allow "า" "ะ" "ำ" "ๆ" "ฯ" too because no thai words > are start with this vowel. (this has solved in body and search bar but it's > still not solved in address bar and find bar.) This is IME dependent. For example, one can achieve this for "ะ", "า", "ำ" using Strict XIM on X: $ LC_CTYPE=th_TH.UTF-8 XMODIFIERS=@im=Strict GTK_IM_MODULE=xim firefox

Thanks for your comments! (In reply to comment #7) > (In reply to comment #4) > > Artit confirmed it still exists on Mac. Is this something that we're using OS > > libraries to determine? > > Ah, yes. The fix for Bug 353776 is on GTK+ only. We need more work for Mac. If you understand what needs to be done, can you file a new bug for fixing this issue on Mac? (In reply to comment #8) > This is IME dependent. For example, one can achieve this for "ะ", "า", "ำ" > using Strict XIM on X: > > $ LC_CTYPE=th_TH.UTF-8 XMODIFIERS=@im=Strict GTK_IM_MODULE=xim firefox Is this something we should fix in our launching script on Linux? If so, can you file a new bug for that?

(In reply to comment #9) > (In reply to comment #8) > > This is IME dependent. For example, one can achieve this for "ะ", "า", "ำ" > > using Strict XIM on X: > > > > $ LC_CTYPE=th_TH.UTF-8 XMODIFIERS=@im=Strict GTK_IM_MODULE=xim firefox > > Is this something we should fix in our launching script on Linux? If so, can > you file a new bug for that? No. It's rather user's preference, depending on what they are using. There can be other kinds of input method frameworks, such as SCIM and iBus. All have different methods to configure. What I meaned to say was that it's not Firefox's functionality. Out of scope here.

Ok. Should we contact the common input method frameworks and ask them to turn on strict by default for Thai, so that things work correctly by default for normal users?

I repeat that it's rather user's preference. Normally, people don't like the input method to be too picky, or they won't be able to type some deliberately non-canonical sequences. For example, when one tries to quote a single vowel when discussing Thai orthography, strict check would block them from typing independent "า" with quotation. And there can be other examples like this. People tend to be happier to take control, while the basic check helps prevent common mistakes. So, I think it's more optimal as the default. Strict check can be annoying and should only be enabled for people who really want it.

Ah ok. I thought it might be a situation where the normal user wouldn't be aware of this type of setting. It sounds like this should be WONTFIX.

This is currently assigned to Prabhat Hegde of Sun. Is Prabhat still active? Should this be marked WONTFIX as Dietrich suggested in Comment 13?

(In reply to comment #14) > This is currently assigned to Prabhat Hegde of Sun. Is Prabhat still active? > Should this be marked WONTFIX as Dietrich suggested in Comment 13? I think the bug still exists on Mac (comment #4).

The bug still exists on Mac (Firefox nightly 4.0b11pre 2011-01-30)

Theppitak, you said in the comments above that this can't be fixed in Firefox, since it's the IME configuration not Firefox that controls this, and that users control that. If that's true, then this bug is WONTFIX.

(In reply to comment #17) > Theppitak, you said in the comments above that this can't be fixed in Firefox, > since it's the IME configuration not Firefox that controls this, and that users > control that. > > If that's true, then this bug is WONTFIX. That was an answer to a different question. In comment #5, Kamonpop asked for more strict filtering than the default, and I said that's configurable. But the main issue of this bug still requires surrounding text support on Mac to achieve even the default.

Ah ok, I thought comment #10 was about all base characters. Theppitak: So does this bug need to do for Mac widgets what you did for gtk in bug 353776?

(In reply to comment #19) > Theppitak: So does this bug need to do for Mac widgets what you did for gtk in > bug 353776? Yes. We need someone to work on it for Mac.

Should we close this an file a new bug for Mac?

(In reply to comment #21) > Should we close this an file a new bug for Mac? I think that's a good idea. Please comment in this bug to point to the new bug number so those who want to follow the new one can. Masayuki may end up being the person to fix the new bug you will file.