936881 - Firefox causes erroneous input method change on OS X Mavericks

Reporter

Description

•

11 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20131109004004

Steps to reproduce:

Using Firefox Aurora on OS X Mavericks (not sure if the problem existed previously, but i certainly can't recall it), there is a very frustrating issue related to keyboard input methods.

My primary language is English, and my keyboard matches this, but i keep the OS X Kotoeri input method enabled for when i need to type in Japanese. Normally, it doesn't become active unless i specifically set it to via the menu bar.

However, in recent versions of Aurora on Mavericks, the browser is automatically switching (or causing the OS to switch) my input method when i click into a text field on a page whose language is set to certain East Asian languages, particularly Korean.

What is especially irritating is that this change is global and does not revert when i leave the page or the browser. As a result, every time i visit a Korean page in Firefox, my keyboard essentially stops working in all applications.

Steps to replicate:

1. Add the Koteori (Japanese) input method via System Preferences > Keyboard > Input Sources. (Specifically, i have two methods added — US and Kotoeri — and in Kotoeri i have the hiragana and katakana modes turned on.)

2. Visit a page with Korean language set via the HTML lang attribute. Examples: daimu.net, naver.com, korean.visitkorea.or.kr.

2. Click into the search box on the page.

4. Start typing — the hiragana input mode will have become active.

Actual results:

Once a text field is selected on a Korean-language Web page, the OS input method switches to Kotoeri's hiragana mode.

Expected results:

Firefox should not change my input method, especially to one that doesn't even match the page language.

ce

Reporter

Comment 1

•

11 years ago

I'm sorry, there's a typo in my step 2 above: Rather than daimu.net, i meant daum.net.

Also:

1. The option in the system Keyboard preferences to 'Automatically switch to a document's input source' is not enabled. Enabling it has no effect.

2. I compared Firefox's behaviour to Safari and Chrome on the same machine, and they did not switch the input method, not even temporarily, not even with the above setting turned on.

3. I have experienced this on three different machines, all running various versions of Mavericks and Aurora.

4. The behaviour is as described on two of the machines. On one of the machines, the hiragana mode is somehow greyed out (apparently an Apple bug), and that one behaves a little differently — the text field uses the hiragana mode anyway (???) but the global input method selection remains what i set it to (US).

5. I tried to replicate this on Japanese and Chinese sites, but i could not — only Korean ones. Additionally, i could not replicate on Korean sites that set the language via meta tags, only ones that set it using <html lang="ko">.

6. As to why it switches to a JAPANESE input method on KOREAN sites, i don't know. I do note that 'Kotoeri' has the same first letters as the ISO code 'ko', so maybe there is some kind of partial pattern matching or something happening where it's trying to find the 'best match', but that's just idle speculation.

7. I also tried to replicate by creating a local HTML file that has lang="ko" set, but i couldn't get it to happen that way. I don't know what the difference is.

ce

Reporter

Updated

•

11 years ago

URL: daum.net

Keywords: inputmethod

Hardware: x86 → x86_64

Loic

Comment 2

•

11 years ago

Are you able to reproduce the issue with the current release, Firefox 25?

URL: daum.net → http://www.daum.net/

Flags: needinfo?(bugs)

Keywords: inputmethod

ce

Reporter

Comment 3

•

11 years ago

Hi there. Yes, i've just tried and i am in fact able to replicate with the latest Firefox 25.

I've also tried creating a new profile (in both versions) and it behaves the same.

ce

Reporter

Updated

•

11 years ago

Flags: needinfo?(bugs)

philippe (part-time)

Comment 4

•

11 years ago

I've reproduced this with the most recent nightly as well as with Firefox 10 ESR. On daum.net and naver.com the switch happens onLoad, on korean.visitkorea.or.kr the switch happens when the user clicks in the input field.

The problem does't happen on e.g apple.com/kr/

philippe (part-time)

Comment 5

•

11 years ago

Checkin the source of daum.net, I see that the inline stylesheet (head of the doc) sets this:

#q { ime-mode: active; }

#q is the search input field at the top of the page.

This is only supported by Firefox on OS X. I suspect this is not really a bug. Still puzzling though that it only seem to affect Firefox on 10.9, though. I can't make this happen on 10.6 and 10.8, even with identically configured user accounts.

I'd be curious if this is reproducible on Win 7+ when a CJK input method & language is activated in the System settings  (e.g. having Japanese activated even if it is not the default language).

ce

Reporter

Comment 6

•

11 years ago

Attached file korean sites.txt — Details

On daum.net and naver.com, the page loads with the search fields focussed. I think that explains the difference in the behaviour between those two and the Visit Korea site.

I tested this like:

1. Load daum.net in a background tab — no IME change

2. Click on daum.net tab — input field is automatically focussed and IME changes to Kotoeri

3. Switch away from tab, reset IME, switch back — IME changes again

4. Click off of input field, switch away from tab, reset IME, switch back — no IME change

Something to note about apple.com/kr is that it uses lang="ko-KR".

I've attached a text file with the URLs and attributes of several Korean-language Web sites, along with the observed behaviour. From the results, i can see that it is not quite as simple as the lang="ko" thing (although all of the ones that did exhibit the problem were set that way).

ce

Reporter

Comment 7

•

11 years ago

Oh we posted at the same time, sorry.

You are right, i think that's exactly it. Looking back over the sites that exhibit the problem, all of them have that CSS property set somewhere.

I do consider this a bug, though, because even if it is useful to force certain keyboard behaviour on certain pages or in certain fields, a Web page should not be able to screw with the settings of my entire operating system. I don't know if that's a Mozilla limitation or an Apple one, but it's terrible.

In the mean time, this user style appears to work around the problem:

* { ime-mode: normal !important; }

Cheers

philippe (part-time)

Comment 8

•

11 years ago

(In reply to kine from comment #7)
 
> I do consider this a bug, though, because even if it is useful to force
> certain keyboard behaviour on certain pages or in certain fields, a Web page
> should not be able to screw with the settings of my entire operating system.
> I don't know if that's a Mozilla limitation or an Apple one,

That is how choosing an input method has behaved on OS X since forever. In Firefox, load google.com and switch to Kotoeri (Hiragana). Then switch to the Finder or Textedit and check - Kotoeri will still be active (unless 'Automatically switch to a document's input source' is enabled in the system preferences).

> but it's terrible.

Lol, thanks for saying it.

Blocks: mavericks-compat

ce

Reporter

Comment 9

•

11 years ago

> That is how choosing an input method has behaved on OS X since forever.

Yeah, that is how choosing one works, but i am not choosing this. Whatever OS X's IME limitations may be, Firefox is allowing a Web site to arbitrarily modify system settings that affect all applications on my computer. I can't recall a precedent for that.

I guess that has to be weighed against the value of automatically switching IMEs, though. I don't know.

Steven Michaud [:smichaud] (Retired)

Comment 10

•

11 years ago

So it sounds like this is an Apple bug (since it happens with other apps than Firefox) -- or maybe it's a design flaw.  If so, this bug is INVALID.

(It also sounds like this bug/feature isn't new with Mavericks.)

ce

Reporter

Comment 11

•

11 years ago

It does not happen with other apps, in the sense that no other browser on OS X allows Web sites to change the IME settings.

Steven Michaud [:smichaud] (Retired)

Updated

•

11 years ago

Flags: needinfo?(phiw)

philippe (part-time)

Comment 12

•

11 years ago

So after lots of testing, the behaviour is correct (and this bug is invalid). If anything, Firefox and 10.9 are more consistent than previous OS.

Assuming in the below the OS language is set to English; all tests are performed with a freshly created user account on iMacs with the Apple JIS USB keyboard attached (it shouldn’t really matter, though)

1/ on 10.6 & 10.8 enable both EN-US kbd layout + Kotoeri input method.

* load daum.net
—> the input method does not change to Kotoeri / Hiragana (independently whether  Kotoeri/Romanji or EN-US was previously selected.

2/ on the same account, enable EN-US-extended instead of EN-US
* load daum.net
—> the input method changes to Kotoeri / Hiragana

3/ Repeat the above on 10.9
—> in both cases, the input method is changed to Kotoeri / Hiragana

On 10.9 -

4/ I activate the following input methods and keyboard layouts: EN-US, Kotoeri, Korean (2-set Korean is the name in English I think).

- test a/
  * The active input method is Kotoeri (Romanji).
  *Load daum.net in Firefox

  —> The page changes the input method to Hiragana

close the page

- test b/
  * cycle through to EN (US flag in the menu bar),
    cycle through to Korean input and back to EN
  * load daum.net

  —> the page changes the input method to Korean

This is all correct behaviour for Kotoeri on 10.9 (it remembers the last use input method and prioritise as such).

----

Interesting note: Camino (using Gecko 1.9.2) & Firefox 3.6 do not switch input methods on 10.9, although the property is supposed to be supported according to the MDN docs [*]

[*] https://developer.mozilla.org/en-US/docs/Web/CSS/ime-mode?redirectlocale=en-US&redirectslug=CSS%2Fime-mode

Status: UNCONFIRMED → RESOLVED

Closed: 11 years ago

Flags: needinfo?(phiw)

Resolution: --- → INVALID

philippe (part-time)

Comment 13

•

11 years ago

(In reply to kine from comment #1)

On one of the
> machines, the hiragana mode is somehow greyed out (apparently an Apple bug),

http://support.apple.com/kb/TS5308

Allison

Comment 14

•

9 years ago

I found this because I was having the same kind of issue, but I only seem to notice it specifically when entering passwords.

Firefox 38, Yosemite 10.10.3

I have US English, Romaji, Hiragana, Katakana, and Colemak keyboard layouts enabled. 

When I click on the password field on scottrade.com (if it loads with "New Member", click Secure Login instead) it changes immediately to Romaji.  I think I've seen it change to Colemak too, which is problematic for password fields, but I don't know off the top of my head which sites I've seen it on or how to reproduce it reliably. 

I don't see any ime-mode styles on that password box, but I did not look through the entire set of stylesheets.  Is this the same bug from 2013 or a different variation?

Steven Michaud [:smichaud] (Retired)

Updated

•

9 years ago

Flags: needinfo?(phiw2)

philippe (part-time)

Comment 15

•

9 years ago

(In reply to Allison from comment #14)
> I found this because I was having the same kind of issue, but I only seem to
> notice it specifically when entering passwords.
> 

> When I click on the password field on scottrade.com (if it loads with "New
> Member", click Secure Login instead) it changes immediately to Romaji.  I
> think I've seen it change to Colemak too, which is problematic for password
> fields, but I don't know off the top of my head which sites I've seen it on
> or how to reproduce it reliably. 
> 
> I don't see any ime-mode styles on that password box, but I did not look
> through the entire set of stylesheets.  Is this the same bug from 2013 or a
> different variation?

That seems to be the default behaviour on OS X for password fields (on any site, that is not specific to the site you highlight above). Safari does the same.

Now, if it changes to Colemak, that would be a problematic behaviour indeed. If you can reproduce that, please file a new bug.

Flags: needinfo?(phiw2)