Closed Bug 1498823 Opened 6 years ago Closed 5 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: 5 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: