Though the Extended Roman Unicode keyboard layout can be selected when focus is on a text input element such as the URL Bar, keyboard layout selection reverts to US once text input is complete. It should be possible to select Extended Roman (U) and have that selection be persistent, even across application restarts. (Might depend on bug 115887. Also dependent on ATSUI bug 121540?)

->pinkerton

I'm guessing this is a duplicate of or related to bug 151110.

-> brade

Nope, not a dup of bug 151110. That's about being unable to enter diacriticals in HTML forms in the content area. You can enter diacriticals in the URL Bar just fine. You can even enable the Unicode keyboard layouts in the URL Bar (in HTML form text fields, you can't).

related to bug 120334?

120334 is in caron code and this one is in cocoa code we support TSM in carbon code. But we have not start to add input method support in cocoa code yet.

For this particular bug, what I see is that Chimera (app) has a setting and Gecko has a different setting; they don't seem to be in synch with each other, nor do they persist.

This seems fixed with the trunk move anyone confirming ?

If it worked back in 2003, it's no longer (completely) working. See also bug 244658, which notes that selecting US Extended in one of location field/search field/browser window disables all Unicode layouts in the other two, which would certainly interfere with persistent selection :)

Do other keyboard layouts "stick"? e.g. Katakana?

(In reply to comment #10) > Do other keyboard layouts "stick"? e.g. Katakana? CJK are outside my realm of knowledge, but if I select Katakana in the Finder and launch Camino, Katakana remains active in text fields (hitting some keys to produce partial glyphs), the general content area, and both the location and search bars. This seems to persist through quit/relaunch, as long as the Finder remains in Katakana. Some notion of "Japanese-ness" persists in Camino even once the Finder is back in US; if I quit Camino, switch the Finder back to US and launch Camino, Camino launches with Romaji active... If I select Katakana after Camino has been launched (Finder=US), Katakana remains active in the text field and content area but otherwise runs into bug 244658, where it's active in the Cocoa chrome or the content area, but not both, and other Unicode layouts get disabled. If I set the Finder to US Extended (née Extended Roman), launch Camino, I'm back to US (whether I load a home page so the focus is in the content area, or blank so the focus is in the location bar). Sometimes the Extended layout will persist in the content area after typing and sometimes it won't (sometimes, though not always, pressing a button will revert it to US), and sometimes simply exiting the text area will revert the entire content area to US...). I see the same behavior with the Mac OS X standard Arabic layout. Part of this is probably comment 7 (and also bug 244658 comment 7), but the Finder has some persistence problems when using "less-common layouts" on US/English OS locales, so there may be some wider OS issues, too.

Moving the IME bugs to 1.1 :-(

Moving IME-related bugs to Camino 1.2 :(

Mass un-setting milestone per 1.6 roadmap. Filter on RemoveRedonkulousBuglist to remove bugspam. Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.

Mass-reassign of bugs still assigned to pinkerton to nobody; filter on "NoMoPinkBugsInCamino".

Has anyone retested this on trunk (where IME has churned in core a fair amount) and Leopard (where the OS is, in my experience, less prone to changing inputs just to mess with me)?

Unless you want to test and/or fix this on 10.4, I'm happy to WFM it; it even seems to persist properly using branch, which means it was probably mostly an OS bug.