Closed Bug 1498823 Opened 6 years ago Closed 6 years ago

Enter to submit text doesn't work in web.whatsapp.com on Linux

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
62 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla66
Tracking Flags:
Tracking Status
firefox65 --- fixed
firefox66 --- fixed

People

(Reporter: james_h143, Assigned: masayuki)

References

Details

Attachments

(4 files)

nightly-ime.log
11.57 KB, text/plain
Details
nightly-ime-22-12-2018.log
524.50 KB, text/plain
Details
nightly-ime-25122018.log
49.41 KB, text/plain
Details
Bug 1498823 - Make KeymapWrapper::FilterEvents() ignore synthesized KeyPress events
47 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
Details | Review
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0 Steps to reproduce: Firefox v62.0.03 - Debian 9 - Cinnamon DE go to whatsapp web select conversation write message press enter with intent to send Actual results: enter does not send the message Expected results: enter should send the message Seems like the issue fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=1423693 may not have been fixed for everyone? killing the ibus process with htop restores functionality
@nakano san, can you please look into this?
Component: Untriaged → Widget: Gtk
Flags: needinfo?(masayuki)
Product: Firefox → Core
Blocks: 1423693
I can confirm this bug. OS: Ubuntu Mate 18.04.1 LTS Firefox: 62.0.3 (64-bit) Input method: IBus/XIM/None Behaviours: . start web.whatsapp.com . choice any client chat . write a message . key enter don't work. Click send button work normally . start gmail . click in the search bar . type anything . key enter don't work. Click search button work normally Chrome works nicely.
Could you attach log file mentioned in bug 1423693 comment 22 and event log shown in the test page?
Flags: needinfo?(masayuki)
I followed the steps the best I could. the command I used to run firefox was this: env MOZ_LOG=nsGtkIMModuleWidgets:5,sync MOZ_LOG_FILE=~/firefox-ime.log ./Programs/firefox/firefox-bin firefox-ime.log was created but nothing was in it. I tried it with other keys as well, still empty
could you attach log that is by https://bugzilla.mozilla.org/show_bug.cgi?id=1423693#c22?
Flags: needinfo?(ph.gachoud)
link is striked out... still valid??
Flags: needinfo?(ph.gachoud) → needinfo?(m_kato)
(In reply to Philippe Gachoud from comment #7) > link is striked out... still valid?? Of course, we need a input method log to fix this.
Flags: needinfo?(m_kato)
Attached file nightly-ime.log —
[:m_kato] ,please see attached
Attachment #9031294 - Attachment mime type: text/x-log → text/plain
Hmm... > [Parent 7200: Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f3ef5f8a400 OnFocusChangeInGecko(aFocus=true), mCompositionState=NotComposing, mIsIMFocused=true > [Parent 7200: Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f3ef5f8a400 SetInputContext(aCaller=0x0x7f3ef6f07400, aContext={ mIMEState={ mEnabled=ENABLED }, mHTMLInputType=text }) These lines mean that we enabled IME for the focused editor. > [Parent 7200: Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f3ef5f8a400 OnKeyEvent(aCaller=0x0x7f3ef6f07400, aEvent(0x0x7f3eee8a1520): { type=GDK_KEY_PRESS, keyval=Return, unicode=0xD, state=, time=2397203, hardware_keycode=36, group=0 }, aKeyboardEventWasDispatched=false) > [Parent 7200: Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f3ef5f8a400 OnKeyEvent(), mMaybeInDeadKeySequence=false, mCompositionState=NotComposing, current context=0x7f3ef5b05f00, active context=0x7f3ef5b05f00, mIMContextID=eIBus, mIsIMInAsyncKeyHandlingMode=true Pressed Enter key without any modifiers (it's usual "Enter" key in the standard position, I mean, didn't change the key mapping). There is no composition, and active IME is iBus and it's in async key handling mode (as usual). > [Parent 7200: Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f3ef5f8a400 SetCursorPosition(aContext=0x0x7f3ef5b05f00), mCompositionTargetRange={ mOffset=4294967295, mLength=4294967295 }mSelection={ mOffset=4294967295, Length()=0, mWritingMode=Horizontal } > [Parent 7200: Main Thread]: E/nsGtkIMModuleWidgets 0x0x7f3ef5f8a400 SetCursorPosition(), FAILED, mCompositionTargetRange and mSelection are invalid This error was caused by that the handler had not known current selection range yet. But this shouldn't be related to this bug. > [Parent 7200: Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f3ef5f8a400 OnKeyEvent(), putting aEvent into the queue... > [Parent 7200: Main Thread]: D/nsGtkIMModuleWidgets 0x0x7f3ef5f8a400 OnKeyEvent(), succeeded, filterThisEvent=true (isFiltered=true, mFallbackToKeyEvent=false, maybeHandledAsynchronously=true), mCompositionState=NotComposing, mMaybeInDeadKeySequence=false The Enter key press event would be handled by iBus asynchronously later so that we didn't do nothing here. > [Parent 7200: Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f3ef5f8a400 OnKeyEvent(aCaller=0x0x7f3ef6f07400, aEvent(0x0x7f3eee8a1520): { type=GDK_KEY_PRESS, keyval=Return, unicode=0xD, state=, time=2397203, hardware_keycode=36, group=0 }, aKeyboardEventWasDispatched=false) > [Parent 7200: Main Thread]: I/nsGtkIMModuleWidgets 0x0x7f3ef5f8a400 OnKeyEvent(), mMaybeInDeadKeySequence=false, mCompositionState=NotComposing, current context=0x7f3ef5b05f00, active context=0x7f3ef5b05f00, mIMContextID=eIBus, mIsIMInAsyncKeyHandlingMode=true This is asynchronously synthesized event by iBus. However, the state is not expected. We assume that state should have "IBUS_HANDLED_MASK" or "IBUS_IGNORED_MASK" here. This must be a bug of iBus. > [Parent 7200: Main Thread]: D/nsGtkIMModuleWidgets 0x0x7f3ef5f8a400 OnKeyEvent(), succeeded, filterThisEvent=false (isFiltered=false, mFallbackToKeyEvent=false, maybeHandledAsynchronously=true), mCompositionState=NotComposing, mMaybeInDeadKeySequence=false However, at here, filterThisEvent is false because iBus returned false for gtk_im_context_filter_keypress(). https://searchfox.org/mozilla-central/rev/fd32b3a6fa3eff1468311f6fcf32b45c117136df/widget/gtk/IMContextWrapper.cpp#944,948 mKeyboardEventWasDispatched was initialized with aKeyboardEventWasDispatched and it was never set to true because no methods which set it to true were called. So, this should be no problem on at least on Nightly... https://searchfox.org/mozilla-central/rev/fd32b3a6fa3eff1468311f6fcf32b45c117136df/widget/gtk/IMContextWrapper.cpp#1019-1021 I'll check 62's source code, though.
Well, 64 and earlier versions just return filterThisEvent so that nothing has changed even on 65 and Nightly. james_h143: - Do you reproduce this bug with safe mode? I mean, some add-ons may consume dispatched keydown/keypress event before web apps. - What keyboard layout(s) do you use with iBus? All of them are bundled in Debian 9?
Flags: needinfo?(james_h143)
masayuki, I have restarted firefox with addons disabled and the issue was still present. My keyboard layout is English (UK)
Flags: needinfo?(james_h143)
I have also tried changing my layout to English (US) as i figured this would have been more likely to come up in regression and again, the issue is present
Came across the same issue on my Ubuntu 18.04 with Firefox 64.00 and to my surprise hitting [backspace] + [enter] submits the message.
(In reply to Hans Gödeke from comment #15) > Came across the same issue on my Ubuntu 18.04 with Firefox 64.00 and to my > surprise hitting [backspace] + [enter] submits the message. also works with alphabetical keys.
I'd like to confirm that do you see similar symptom in other web apps? And do you see one set of keydown, keypress and keyup events in https://w3c.github.io/uievents/tools/key-event-viewer.html when you type Enter in the <input> element?
I tried to reproduce this bug on Ubuntu and Debian Cinnamon with en-US keyboard layout and ibus, but I still cannot reproduce this... why??
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #17) > I'd like to confirm that do you see similar symptom in other web apps? And > do you see one set of keydown, keypress and keyup events in > https://w3c.github.io/uievents/tools/key-event-viewer.html when you type > Enter in the <input> element? The WhatsApp web app is the only website I came across with this issue. Tracking the events yields the expected results with the enter key yielding the appropriate <keydown> - <keypress> - <keyup> events. UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #18) > I tried to reproduce this bug on Ubuntu and Debian Cinnamon with en-US > keyboard layout and ibus, but I still cannot reproduce this... why?? The behavior is the same for me no matter which keyboard I am using (UK, US, DE)
I still don't have idea, but I really would like to fix this bug in this year. Usually, we receive IME/keyboard bugs on Linux which depend on environments. Against for that, we provide logging function. However, oddly, attachment 9031294 [details] didn't get useful information. We should think there are some other conditions to reproduce this bug. If you always reproduce this bug in WhatsApp web, i.e., Enter key does not submit your comment anytime, could you give us another log file with the following steps? 1. Launch Nightly with following env: MOZ_LOG=nsGtkIMModuleWidgets:5,KeymapWrapperWidgets:5,sync MOZ_LOG_FILE=~/nightly-ime.log 2. Copy some text. 3. Open WhatsApp web and start a chat. 4. Paste it with mouse (middle click or from context menu). 5. Type Enter to submit. 6. Close Firefox with menu, [File] -> [Exit]. Because I guess that there is something different for ibus between usual <input> and the editor in WhatsApp web's editor.
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #21) > I still don't have idea, but I really would like to fix this bug in this > year. > > Usually, we receive IME/keyboard bugs on Linux which depend on environments. > Against for that, we provide logging function. However, oddly, attachment > 9031294 [details] didn't get useful information. We should think there are > some other conditions to reproduce this bug. > > If you always reproduce this bug in WhatsApp web, i.e., Enter key does not > submit your comment anytime, could you give us another log file with the > following steps? > > 1. Launch Nightly with following env: > MOZ_LOG=nsGtkIMModuleWidgets:5,KeymapWrapperWidgets:5,sync > MOZ_LOG_FILE=~/nightly-ime.log > 2. Copy some text. > 3. Open WhatsApp web and start a chat. > 4. Paste it with mouse (middle click or from context menu). > 5. Type Enter to submit. > 6. Close Firefox with menu, [File] -> [Exit]. > > Because I guess that there is something different for ibus between usual > <input> and the editor in WhatsApp web's editor. As requested
I'm encountering some more keyboard glitches with keypressed in whatsapp which are not taken when pressed quickly, even having a logitech G710+ which is a heavy qlity keyboard and not having this problem on other textfields. I unfortunately need more infos to be able to "Launch Nightly with following env:" where can I find it?
Comment on attachment 9033046 [details] nightly-ime-22-12-2018.log Thanks!
Attachment #9033046 - Attachment mime type: text/x-log → text/plain
(In reply to Philippe Gachoud from comment #23) > I'm encountering some more keyboard glitches with keypressed in whatsapp > which are not taken when pressed quickly, even having a logitech G710+ which > is a heavy qlity keyboard and not having this problem on other textfields. > I unfortunately need more infos to be able to "Launch Nightly with following > env:" where can I find it? The latest firefox nightly build can be found here: https://www.mozilla.org/en-GB/firefox/channel/desktop/ to run in env above navigate to the nightly directory on your computer and run env MOZ_LOG=nsGtkIMModuleWidgets:5,KeymapWrapperWidgets:5,sync MOZ_LOG_FILE=~/nightly-ime.log ./firefox Ensure you have all existing firefox windows closed before you do this though. The log will appear in your home directory. Remember the only keystroke you should perform during this test is the key you are testing. everything else should be copy pasted in
Oddly, only from attachment 9033046 [details], Gecko dispatched "keydown" and "keypress" events for the Enter key press correctly. However, the log does not enough information due to our issue. So, I'm building new build to collect more information (logging result of initialized "keydown" and "keypress" events). I'll tell you URL to download patched build soon. I hope that it lets me know the issue, but I'm not 100% sure if it would because after dispatching keyboard event from widget, XP widget *might* ignore them unexpectedly.
I tried to reproduce this bug with newly installed Ubuntu 18.04 LTS. However, even if I install it with English or German language, I cannot reproduce this. I guess that you who can reproduce this bug perhaps have installed something which affects iBus behavior, or global key event hooking apps like a11y tools.
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #27) > Could you attach same log as comment 21 with one of the following builds? > Really sorry for I request a lot to you. > > 32bit: > https://queue.taskcluster.net/v1/task/LLP1xnwmRLi29u4MAcFLKQ/runs/0/ > artifacts/public/build/target.tar.bz2 > 64bit: > https://queue.taskcluster.net/v1/task/RM2-OwfXRj6gpLSF_VWbVQ/runs/0/ > artifacts/public/build/target.tar.bz2 The following builds get better log, please use one of them instead: 32bit: https://queue.taskcluster.net/v1/task/YxUhqITSSNaC8Ui7fzuBZA/runs/0/artifacts/public/build/target.tar.bz2 64bit: https://queue.taskcluster.net/v1/task/GkSuVHeSS2qXenaU9PTJ8g/runs/0/artifacts/public/build/target.tar.bz2
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #29) > (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #27) > > Could you attach same log as comment 21 with one of the following builds? > > Really sorry for I request a lot to you. > > > > 32bit: > > https://queue.taskcluster.net/v1/task/LLP1xnwmRLi29u4MAcFLKQ/runs/0/ > > artifacts/public/build/target.tar.bz2 > > 64bit: > > https://queue.taskcluster.net/v1/task/RM2-OwfXRj6gpLSF_VWbVQ/runs/0/ > > artifacts/public/build/target.tar.bz2 > > The following builds get better log, please use one of them instead: > 32bit: > https://queue.taskcluster.net/v1/task/YxUhqITSSNaC8Ui7fzuBZA/runs/0/ > artifacts/public/build/target.tar.bz2 > 64bit: > https://queue.taskcluster.net/v1/task/GkSuVHeSS2qXenaU9PTJ8g/runs/0/ > artifacts/public/build/target.tar.bz2 log for the 64 bit build attached. I should also mention I use Ubuntu regularly on my laptop which is also 18.04. I do not get that issue on Ubuntu, only Debian. The log created above comes from a fresh install of Debian too. the only thing i have installed on that one is some virtual box tools. i am still getting the issue. The installer I used for that Debian installation is debian-live-9.5.0-amd64-cinnamon.iso
Flags: needinfo?(james_h143)
Attachment #9033241 - Attachment mime type: text/x-log → text/plain
Thank you very much!! Probably, I got the cause of this bug. Looks like that keydown and keypress events are marked as "repeated" even though it's first Enter key press. I'm retrying to create the environment to reproduce this bug in my environment...
> The installer I used for that Debian installation is debian-live-9.5.0-amd64-cinnamon.iso I reproduced this bug with debian-live-9.6.0-amd64-cinnamon.iso, thanks! But oddly, I cannot reproduce this with debian-9.6.0-amd64-netinst.iso even if I installed cinnamon.
> I/KeymapWrapperWidgets FilterEvents(aXEvent={ type=KeyPress, xkey={ keycode=0x00000024, state=0x00000000 } }, aGdkEvent={ state=0x00000000 }), detected first keypress > I/KeymapWrapperWidgets HandleKeyPressEvent(aWindow=0x7fb901bba400, aGdkKeyEvent={ type=GDK_KEY_PRESS, keyval=Return(0xFF0D), state=0x00000000, hardware_keycode=0x00000024, is_modifier=FALSE }) > I/KeymapWrapperWidgets HandleKeyPressEvent(), the event was handled by IMContextWrapper Here is that the Enter key press is consumed by ibus for handling asynchronously. > I/KeymapWrapperWidgets FilterEvents(aXEvent={ type=KeyPress, xkey={ keycode=0x00000024, state=0x00000000 } }, aGdkEvent={ state=0x00000000 }), detected repeating keypress Then, duplicated Enter key press event is fired again, but this is NOT fired via FilterEvents() in usual environment. Additionally, the |state| values don't have the IBUS_IGNORED_MASK flag. At this time, FilterEvents() thinks that it's generated by auto-repeat because of second GDK_KEY_PRESS event for same hardware_keycode. > I/KeymapWrapperWidgets HandleKeyPressEvent(aWindow=0x7fb901bba400, aGdkKeyEvent={ type=GDK_KEY_PRESS, keyval=Return(0xFF0D), state=0x00000000, hardware_keycode=0x00000024, is_modifier=FALSE }) > D/KeymapWrapperWidgets 0x7fb8fac88900 InitInputEvent, aModifierState=0x00000000, aInputEvent={ mMessage=eKeyDown, mModifiers=0x0000 (Shift: FALSE, Control: FALSE, Alt: FALSE, Meta: FALSE, OS: FALSE, AltGr: FALSE, CapsLock: FALSE, NumLock: FALSE, ScrollLock: FALSE }) > I/KeymapWrapperWidgets 0x7fb8fac88900 InitKeyEvent, modifierState=0x00000000 aKeyEvent={ mMessage=eKeyDown, isShift=FALSE, isControl=FALSE, isAlt=FALSE, isMeta=FALSE , mKeyCode=0x0D, mCharCode=NULL (0x0000), mKeyNameIndex=Enter, mKeyValue="", mCodeNameIndex=Enter, mCodeValue="", mLocation=KEY_LOCATION_STANDARD, mIsRepeat=TRUE } > I/KeymapWrapperWidgets HandleKeyPressEvent(), dispatched eKeyDown event and it wasn't consumed Finally, keydown event is dispatch with setting .repeat to true. > D/KeymapWrapperWidgets 0x7fb8fac88900 InitInputEvent, aModifierState=0x00000000, aInputEvent={ mMessage=eKeyPress, mModifiers=0x0000 (Shift: FALSE, Control: FALSE, Alt: FALSE, Meta: FALSE, OS: FALSE, AltGr: FALSE, CapsLock: FALSE, NumLock: FALSE, ScrollLock: FALSE }) > I/KeymapWrapperWidgets 0x7fb8fac88900 InitKeyEvent, modifierState=0x00000000 aKeyEvent={ mMessage=eKeyPress, isShift=FALSE, isControl=FALSE, isAlt=FALSE, isMeta=FALSE , mKeyCode=0x0D, mCharCode=NULL (0x0000), mKeyNameIndex=Enter, mKeyValue="", mCodeNameIndex=Enter, mCodeValue="", mLocation=KEY_LOCATION_STANDARD, mIsRepeat=TRUE } > I/KeymapWrapperWidgets HandleKeyPressEvent(), dispatched eKeyPress event (status=nsEventStatus_eIgnore) And same for keypress. So, we need to distinguish whether coming event is synthesized asynchronously in FilterEvents().
Assignee: nobody → masayuki
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
We're logging all key events on any widgets to check with filter method, whether a key is pressed to set WidgetKeyboardEvent::mIsRepeat properly. If iBus and Fcitx work as expected, they synthesize key events with setting their own modifier state which indicate the event is synthesized by IME. In this case, the synthesized key events are not caught by the filter. However, in some environment, they keep handling key events asynchronously but they or something other module synthesize key events without the flag and such events are caught by the filter. Therefore, we decided that the synthesized events are always generated by auto-repeat. This patch makes KeymapWrapper::FilterEvents() ignore coming KeyPress events if: - the time is exactly same as previous KeyPress event - and IMContextWrapper instance is now waiting a GDK_KEY_PRESS event - and hardware_keycode of waiting GDK_KEY_PRESS event is same as keyCode of the previous KeyPress event We know that only in some cases of dead key handling, we receive unexpected synthesized GDK_KEY_PRESS events. Therefore, this patch does NOT fix such cases, but I don't have a good idea to fix it.
(In reply to Masayuki Nakano [:masayuki] (JST, +0900)(Away from Bugmail Dec 27-Jan 3)) from comment #35) > FYI: Here are patched builds: > 32bit: > https://queue.taskcluster.net/v1/task/bQ-JZh2QToupyKGpJDS0SA/runs/0/ > artifacts/public/build/target.tar.bz2 > 64bit: > https://queue.taskcluster.net/v1/task/MFEl2xbSTZq9-4SJ5AoYeg/runs/0/ > artifacts/public/build/target.tar.bz2 The patched 64 bit build does seem to resolve the issue for me
> We know that only in some cases of dead key handling, we receive unexpected > synthesized GDK_KEY_PRESS events. Therefore, this patch does NOT fix such > cases, but I don't have a good idea to fix it. I worried about same issue as bug 1505147, but I cannot reproduce similar behavior with Debian-Cinnamon. Therefore, I dropped this paragraph from the commit message (and I rewrote the commit message with clearer explanation).
(In reply to james_h143 from comment #36) > (In reply to Masayuki Nakano [:masayuki] (JST, +0900)(Away from Bugmail Dec > 27-Jan 3)) from comment #35) > > FYI: Here are patched builds: > > 32bit: > > https://queue.taskcluster.net/v1/task/bQ-JZh2QToupyKGpJDS0SA/runs/0/ > > artifacts/public/build/target.tar.bz2 > > 64bit: > > https://queue.taskcluster.net/v1/task/MFEl2xbSTZq9-4SJ5AoYeg/runs/0/ > > artifacts/public/build/target.tar.bz2 > > The patched 64 bit build does seem to resolve the issue for me Thank you for the confirmation!
Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/11963e8ad79f Make KeymapWrapper::FilterEvents() ignore synthesized KeyPress events r=m_kato
Bug disappeared from me yesterday on version 60.4.0esr (64-bit) debian 9.... all strange keyboard glitches are solved...
(In reply to Philippe Gachoud from comment #40) > Bug disappeared from me yesterday on version 60.4.0esr (64-bit) debian 9.... > all strange keyboard glitches are solved... But.... remaining into mail search txtbox, enter key doesn't validate the search... maybe whatsapp changed their code!
Oh, really? If so, it might be better to stop uplifting the fix on Beta...
(In reply to Masayuki Nakano [:masayuki] (JST, +0900)(Away from Bugmail Dec 27-Jan 3)) from comment #42) > Oh, really? If so, it might be better to stop uplifting the fix on Beta... I'm still getting the issue on the non patched builds. Maybe Philippes issue was different?
https://hg.mozilla.org/mozilla-central/rev/11963e8ad79f
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox66: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
now today its not working anymore!!! really strange.... still on gmail search its not working you could check also this case which could have similarities.... i remember having an old vm which was i think working does it hwlp if I provide more info about that?
(In reply to Philippe Gachoud from comment #45) > now today its not working anymore!!! really strange.... still on gmail > search its not working you could check also this case which could have > similarities.... i remember having an old vm which was i think working does > it hwlp if I provide more info about that? Hi philippe Have you tried the latest patched build masayuki linked above in comment 35? Don't click the link from my confirmation of it working, I replied to the wrong comment.
(In reply to james_h143 from comment #43) > (In reply to Masayuki Nakano [:masayuki] (JST, +0900)(Away from Bugmail Dec > 27-Jan 3)) from comment #42) > > Oh, really? If so, it might be better to stop uplifting the fix on Beta... > > I'm still getting the issue on the non patched builds. Maybe Philippes issue > was different? Thanks. Then, we should fix this on beta too.
Comment on attachment 9033327 [details] Bug 1498823 - Make KeymapWrapper::FilterEvents() ignore synthesized KeyPress events [Beta/Release Uplift Approval Request] Feature/Bug causing the regression: None User impact if declined: Although this bug occurs only on some environments (we confirmed only debian-cinnamon environment installed from ISO image). However, this makes users on such environment cannot use WhatsApp. Is this code covered by automated tests?: No Has the fix been verified in Nightly?: Yes Needs manual test from QE?: No If yes, steps to reproduce: List of other uplifts needed: Bug 1516323 Risk to taking this patch: Low Why is the change risky/not risky? (and alternatives if risky): On Linux, we cannot check whether each key event is caused by auto-repeat. For solving this problem, we hook all key events on all widgets. However, only in such broken environment, synthesized key events by IME are also posted into the normal event queue. Therefore, we receive 2 key events for every key-press and key-release. So, any key press are decided as caused by auto-repeat since same hardware key events are fired twice and only the second key events cause dispatching DOM keydown/keypress events. Like WhatsApp, if keydown/keypress events whose .repeat are true are ignored, users cannot use some (or all) keys on such web apps. String changes made/needed: no
Attachment #9033327 - Flags: approval-mozilla-beta?
Comment on attachment 9033327 [details] Bug 1498823 - Make KeymapWrapper::FilterEvents() ignore synthesized KeyPress events [Triage Comment] Fixes a Linux-only issue causing users on some systems to be unable to use WhatsApp. Approved for 65.0b8.
Attachment #9033327 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(In reply to Masayuki Nakano [:masayuki] (JST, +0900)(sick) from comment #48) > Needs manual test from QE?: No Setting this as qe-verify-.
Flags: qe-verify-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: