Closed Bug 791300 Opened 8 years ago Closed 3 years ago

Chained dead key won't be handled correctly

Categories

(Core :: Widget: Win32, defect, P3)

15 Branch
x86
Windows XP
defect

Tracking

()

VERIFIED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: rlndkfmn+mozilla, Assigned: masayuki)

References

Details

(Whiteboard: tpi:+)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

Click or tab to focus on a text area, for instance in a bug report. Type a dead key, e.g. diaeresis ('¨') and then the base character of an accented letter, e.g. 'u'


Actual results:

The base character appears, as if the dead key had never been pressed.


Expected results:

The accented letter ('ü') should appear.

This bug is a regression from the previous version (14.0.1), as the desired functionality was present there.
Duplicate of this bug: 792519
^+ u =û , ´+u=ú

Seems to be wfm with 
Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/18.0 Firefox/18.0 SeaMonkey/2.15a1
and Firefox 15
Component: Untriaged → Editor
Product: Firefox → Core
Component: Editor → Widget: Win32
I have tested this with the 14.0.1, 15.0.1 and the nightly 18.0a1 (2012-09-21) builds, in combination with several keyboard layouts: In the latter two, dead keys that are specified with a following "dead" entry (first byte is 0xFF) in the pVkToWcharTable in the KBDTABLES structure are handled correctly; diacritics that are in the pDeadKey entry in KBDTABLES however are not. In the first build, both are handled correctly.
Summary: Dead keys non-functional in text forms and address bar → Diacritics non-functional in text forms and address bar
After more testing, it seems like the bug is related to this: If the DEADKEY entry in the pDeadKeys member of KBDTABLES has its uFlags member set to DKF_DEAD (=0x0001), then the key is not processed again but is just dropped and consequently the next key is registered as a direct key and not as another index into the dead-keys table.

Thus, there seems to be code in the keyboard handler which incorrectly assumes that a dead key (marked as WCH_DEAD) always generate a character on the next keypress and not another dead key.
Summary: Diacritics non-functional in text forms and address bar → Dead-key diacritics non-functional in text forms and address bar
Looking at the source code, I see there is a comment in function KeyboardLayout::GetDeadKeyCombinations in file widget/windows/KeyboardLayout.cpp at line 1058 (commit d912ce in the mozilla-central repo) that dead key chaining is not supported.

However, that line originates from pre-Mercurial times, and this functionality was in as late as release 14.
Hello. I have spent much time configuring my keyboard layout only to find out that many applications actually don't support chained deadkeys, Firefox being one of them. Can you please do something with this issue?

Thank you, Drekin.
Still no progress? Do you have information about support of chained dead keys feature among other browsers? Since I cannot do anything, I'll provide a longer explanation of my use case.

I'd like to be able to type all the characters I use on my keyboard rather than use some special and not universal methods – e.g. why to rely on automatic correction in Word from hyphen to dash or from inches to quotes when one can just write dash or quotes directly using the keyboard? I also write math text in the browser – for example on math.exchange. Why to write cryptic TeX commands like \nsubseteq instead of writing directly ⊈?

In order to be able to write all those characters, one has to write custom keyboard layout which isn't easy on Windows. The chained dead keys feature helps much in organising all the characters one wants to write. For example to produce ⊆, one has to type sequence (Left, s), where Left is a helper deadkey, under my layout. And similarily, (Right, s) gives ⊇, (Left, e) gives ∈, (Right, e) gives ∋. There are also negations of these symbols: ⊈, ⊉, ∉, ∌. The negation gives a new independent dimenstion in the structure of characters and so is most naturally implemented by using chained dead keys in the layout: (Not, Left, s) for ⊈, etc. And one can also use (Left, Not, s) for ⊊.

The multiplicative nature of chained dead keys makes them very useful when defining rich keyboard layouts and it's a pity that even massively used and robust applications like Firefox browser don't support them.
> Do you have information about support of chained dead keys feature among other browsers?

Chained dead keys seems to be functional in both Chrome 24 and Internet Explorer 8 at least. They also work in Firefox on Linux/X.org. It seems to be only the Windows version of Firefox that has attempted to reimplement the system keyboard handler.
(In reply to Roland Kaufmann from comment #8)
> > Do you have information about support of chained dead keys feature among other browsers?
> 
> Chained dead keys seems to be functional in both Chrome 24 and Internet
> Explorer 8 at least. They also work in Firefox on Linux/X.org. It seems to
> be only the Windows version of Firefox that has attempted to reimplement the
> system keyboard handler.

Is the reimplementing of the system keyboard handler necessary? Can't Firefox just use some Windows API function?
Is there no one else interested in the issue?
Hi, I just created my bugzilla account today to BUMP this issue. For many cases chained deadkeys are very practical. They are one of the easier methods to implement a Compose key in Windows. I myself am the developer of a keyboard layout, that makes use of them. 

It is really frustrating to have to write many of the needed non english special characters using notepad and copy pasting them one by one into Firefox. It's like being set back in time to Win 3.11 and charmap.exe. 

Microsoft Edge 25.10586.0.0 (the browser I never use) and Internet Explorer 11.162.10586.0 (the browser used to download Firefox) handle chained deadkeys correctly, like all of my other Windows programs.
Hey Masayuki, is this something we need to look at?
Flags: needinfo?(masayuki)
Whiteboard: tpi:?
Oops, sorry for missed to catch this.

I rewrote text input handling in Firefox 52 (current Nightly). Do you still reproduce this with the latest Nightly? <https://nightly.mozilla.org/>

Comment 5 makes sense to explain what this bug is caused by. KeyboardLayout class is not enough level to compute dead key sequence.  Therefore, we stopped using it at handling text input. Currently, NativeKey respect following WM_CHAR messages when there is one or more WM_(SYS)CHAR messages.  Otherwise, for example, at computing KeyboardEvent.key when Ctrl key is pressed, KeyboardLayout class's information is used.  In other words, current Nightly build must input text which are translated by TranslateMessage() API from WM_KEYDOWN to WM_(SYS)CHAR(s).
Flags: needinfo?(masayuki) → needinfo?(rlndkfmn+mozilla)
FYI: Unfortunately, rewriting the text input handling of Windows is pretty risky change, of course. Therefore, it's won't be uplifted to 51 nor 50.
Ah, or, when a dead key sequence causes only one character, that might be fixed by bug 1293505. If so, 50 (current, Beta, already in RC mode) has a fix.
Hi Masayuki,

Thank you for looking into this issue! 

I have tested Firefox Nightly 52.0a1 (2016-11-04) (64-bit) today, and chained dead-keys still don't work. Neither in the address bar, the search bar, nor in text input fields on websites.
(In reply to lengyel.botond from comment #16)
> I have tested Firefox Nightly 52.0a1 (2016-11-04) (64-bit) today, and
> chained dead-keys still don't work. Neither in the address bar, the search
> bar, nor in text input fields on websites.

Wow, really? I have no idea what is the cause of the bug...

Could you attach a log file of our internal behavior to this bug or let me know what keyboard layout has the chained dead keys?

If you can, please set following env *before* launching Nightly. (Currently, you can log the behavior only with Nightly.)

MOZ_LOG=NativeKeyWidgets:4,KeyboardLayoutWidgets:4,sync
MOZ_LOG_FILE=~/fx.log

Then, launch Nightly, set focus to the search bar and try to type only a few keys which can reproduce this bug. Finally, close the Nightly with mouse.

Then, the behavior is logged into c:\users\<user name>\fx.log.  Could you post it to this bug from the link of "Add an attachment" above?

Please be careful, the log file includes any keyboard inputs.  Therefore, do NOT type something your private information like password during logging the behavior.
Flags: needinfo?(rlndkfmn+mozilla) → needinfo?(lengyel.botond)
The keyboard layout using chained dead-keys is developed by myself, as a dual layout for the modern day Hungarian Latin script and the Old Hungarian script (https://en.wikipedia.org/wiki/Old_Hungarian_alphabet) in Unicode since June 2015.

The layout is dual, because of the possibility to switch between the two scripts with one key-press (VK15 toggleable) in place of the right Ctrl button.

My system is called "HUNIcode" (www.hunicode.hu), and I have besides a completely customized layout also created one called "HUNIcode QWERTY" which is as close to the US keyboard layout as possible. This one uses the chained dead keys for special characters (http://www.hunicode.hu/blogs/post/Megjelent-a-HUNIcode-QWERTY-1-1/) for languages of minorities in Hungary (http://www.hunicode.hu/blogs/post/A-nemzetis%C3%A9gek-%C3%ADr%C3%A1sjeleinek-megjelen%C3%ADt%C3%A9se-a-HUNIcode-QWERTY-vel/) and other European languages (http://www.hunicode.hu/blogs/post/Idegen-nyelvek-bet%C5%B1i/).

The keyboard layout can be seen on my printable keyboard-stickers (http://www.hunicode.hu/files/qwerty/1.1/HUNIcode_QWERTY_Layout.pdf)

The starting key of this key-press sequences (called KÖT in my Hungarian blog posts) is the key [\|] next/above the return key, but it is producing a Zero-Width-Joiner in Old Hungarian mode, which is needed for many ligatures. In Latin Mode it acts as a deadkey based on the ZWJ, but all deadkey sequences start with the ZWJ and the following two keystrokes define the output character. (Chained deadkeys - imitating the Linux compose key behavior).

Because Firefox support was essential to me I have circumvented this issue in ver 1.1 for the time being, by assigning the Right Windows key the keyvalue VK96 which acts as an additional modifier, and can be pressed together with the first key of the two-key-compose-sequences. Making them into single deadkeys. But I still prefer the original way with the 3 consecutive keypresses to produce special characters, which works in essentially all other programs. The VK96 key adds an additional layer of complexity to my layout and was only introduced because of this Firefox bug. If this is fixed, i really consider removing this modifier key again.

----

Now to the log file: I have slightly modified my layout for this test, to rule out problems with ZWJ, so that close bracket ] now also acts as a deadkey, and "].." should produce "…". So I set the environment variables, opened Nightly and this was the first thing i entered into the search-field, but it only produced "." so I followed with a SPACE and pressed [VK96]+[.] followed by another [.] which produced the intended "…". Then I closed Nightly.

I hope the logfile helps you identify the problem.
Flags: needinfo?(lengyel.botond)
Thank you for the log. Looks like that KeyboardLayout treats 2nd dead key is normal keypress even if it's followed by WM_DEADCHAR. I'll take a look.
Assignee: nobody → masayuki
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Dead-key diacritics non-functional in text forms and address bar → Chained dead key won't be handled correctly
Priority: -- → P3
Whiteboard: tpi:? → tpi:+
Although, if there is some keyboard layouts which have chained dead keys and are available without something to install, we can test the patch's changes automatically. I don't find such keyboard layouts...
Comment on attachment 8809701 [details]
Bug 791300 KeyboardLayout should respect following WM_(SYS)DEADCHAR messages for supporting chained dead keys

https://reviewboard.mozilla.org/r/92246/#review92254
Attachment #8809701 - Flags: review?(m_kato) → review+
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/cac0f33c9919
KeyboardLayout should respect following WM_(SYS)DEADCHAR messages for supporting chained dead keys r=m_kato
https://hg.mozilla.org/mozilla-central/rev/cac0f33c9919
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
I just wanted to confirm that this bug is resolved. I have tested my layout 'HUNIcode QWERTY' with Nightly 52.0a1 (2016-11-12) (64-bit) and all chained deadkeys work correctly. Thank you guys :-)
Thank you your confirmation!

FYI: Unfortunately, the fix depends on bug 1303273 and some bugs which are blockers of it. The bug fixes are really risky to uplift. Therefore, this bug fix cannot be uplift even though this is very serious bug for such keyboard layout users. I'm really sorry for the delay of fixing such serious bugs.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.