If plug-ins disable non-Roman keyboard layout and they don't recover the state, Gecko doesn't recover it

RESOLVED FIXED

Status

()

Core
Widget: Cocoa
P1
major
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: masayuki, Assigned: masayuki)

Tracking

(6 keywords)

1.9.2 Branch
x86
Mac OS X
flashplayer, inputmethod, intl, jp-critical, verified1.9.1, verified1.9.2
Points:
---

Firefox Tracking Flags

(status2.0 unaffected, blocking1.9.2 needed, status1.9.2 .11-fixed, blocking1.9.1 needed, status1.9.1 .14-fixed)

Details

(URL)

Attachments

(1 attachment)

(Assignee)

Description

7 years ago
Created attachment 476234 [details] [diff] [review]
Patch v1.0

1. Load above page with Fx3.6 and Flash Player 10.1.x.x
2. Click a link in the Flash Player which is center of the page (the radio program list)

Then, you cannot use non-Roman keyboard layout on Fx.

Flash Player disables non-Roman keyboard layout and if you click the link, Flash Player doesn't recover the keyboard layout state when it's destroying. Gecko stores latest keyboard layout state when Gecko changes it because 10.4 doesn't provide any APIs for getting the state. And Gecko reduces unnecessary API call at nsTSMManager::SetRomanKeyboardsOnly(). Therefore, Gecko doesn't restore the keyboard state until Gecko's password field gets focus.

# NOTE #1: This bug isn't reproduced on Minefield, probably, the reason is that Minefield uses new APIs which are usable 10.5 and later.
# NOTE #2: This bug isn't reproduced with Flash Player 10.0.x.x. So, this is a regression of Flash Player.
Attachment #476234 - Flags: review?(smichaud)
(Assignee)

Updated

7 years ago
blocking1.9.2: --- → ?
status1.9.2: --- → ?
status2.0: --- → unaffected
(Assignee)

Updated

7 years ago
Priority: -- → P1
(Assignee)

Comment 1

7 years ago
This bug can be reproduced on Fx3.5 too. However, it's going to be dropped but SeaMonkey is going to continue to use 1.9.1 for a while. So, we should fix this bug on 1.9.1 too.
blocking1.9.1: --- → ?
status1.9.2: ? → ---
I can't reproduce this bug (testing in FF 3.6.9 on OS X 10.5.8) ... or
at least I don't think I can.

Here's what I did:

1) Load this bug's URL (http://www.tbs.co.jp/radio/todays954/) and
   click somewhere in the Flash object.

   Notice that it's no longer possible to choose Kotoeri Hiragana or
   Katakana from the "flags" menu (those choices are greyed out).

2) Click elsewhere in the page.

   Now it's once again possible to choose Hiragana or Katakana.

3) Click on the Flash object -- Hiragana and Katakana are greyed out.

4) Switch tabs -- Hiragana and Katakana are no longer greyed out.

5) Switch back to the tab with http://www.tbs.co.jp/radio/todays954/
   in it -- Hiragana and Katakana are still not	greyed out.

6) Click on the Flash object -- Hiragana and Katakana are greyed out.

7) Close the current tab (with http://www.tbs.co.jp/radio/todays954/
   in it) -- Hiragana and Katakana are no longer greyed out.

Later I'll try it on OS X 10.6.4.
(Following up comment #3)

I get the same results on OS X 10.6.4.

By the way, on both OS versions I tested with en-US Firefox and the preferred language was set to English.
(Assignee)

Comment 4

7 years ago
Click a link in the Flash Object. Then, you'll open a page on current tab. Then, the keyboard layout limitation isn't canceled.

I can reproduced this bug on 10.5 and 10.6. The original reporter in Japan said that he/she can reproduce this bug on 10.4 too.
CC'ing Charles because it appears it might also be a Flash regression
> Click a link in the Flash Object. Then, you'll open a page on
> current tab.  Then, the keyboard layout limitation isn't canceled.

OK, thanks.  Now I can reproduce it.
Comment on attachment 476234 [details] [diff] [review]
Patch v1.0

This looks fine to me.
Attachment #476234 - Flags: review?(smichaud) → review+
(Assignee)

Comment 8

7 years ago
Comment on attachment 476234 [details] [diff] [review]
Patch v1.0

Thank you, Steven.

This patch just removes an optimizing code for reducing API call. I think that this change doesn't affect to performance.
Attachment #476234 - Flags: approval1.9.2.11?
Attachment #476234 - Flags: approval1.9.1.14?
(Assignee)

Comment 9

7 years ago
NOTE: the method is called at focus moving only when IME state is changed by new focused content.
blocking1.9.1: ? → needed
blocking1.9.2: ? → needed
status1.9.1: --- → wanted
status1.9.2: --- → wanted
Comment on attachment 476234 [details] [diff] [review]
Patch v1.0

Approved for 1.9.2.11 and 1.9.1.14, a=dveditz for release-drivers
Attachment #476234 - Flags: approval1.9.2.11?
Attachment #476234 - Flags: approval1.9.2.11+
Attachment #476234 - Flags: approval1.9.1.14?
Attachment #476234 - Flags: approval1.9.1.14+
(Assignee)

Comment 11

7 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c0c261de23ec
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e532600954d0
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
status1.9.1: wanted → .14-fixed
status1.9.2: wanted → .11-fixed
Resolution: --- → FIXED
Verified fixed in 1.9.2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11pre) Gecko/20100923 Namoroka/3.6.11pre. Verified fixed in 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.14pre) Gecko/20100923 Shiretoko/3.5.14pre.
Keywords: verified1.9.1, verified1.9.2
(Assignee)

Updated

7 years ago
Depends on: 601440
You need to log in before you can comment on or make changes to this bug.