Closed Bug 1423693 Opened 7 years ago Closed 6 years ago

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

Categories

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

Product:
Core
Component:
Widget: Gtk
Platform:
All
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla61
Tracking Flags:
Tracking Status
firefox61 --- fixed

People

(Reporter: luisccgoncalves, Assigned: masayuki)

References

Details

(Keywords: inputmethod)

Attachments

(3 files)

log_file_nightly.log
12.16 KB, text/plain
Details
log_file_quantum_v59.log
6.71 KB, text/plain
Details
Bug 1423693 - Make IMContextWrapper::Init() resolve actual IM if active IM context ID is "xim" and there is XMODIFIERS env
59 bytes, text/x-review-board-request
m_kato
: review+
Details 
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171201011234

Steps to reproduce:

Open web.whatsapp.com, select a contact, write a message and press enter.


Actual results:

Nothing happens.


Expected results:

Should send message. Pressing the "send" button works.
Does not work on Linux in a clean install, works in other browsers on Linux an in Firefox on windows.
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Firefox: 59.0a1, Build ID 20171210220040

I have not managed to reproduce the issue on Ubuntu 14.04 x64, Arch Linux x64 and Windows 10 x64 with Firefox release (57.0.2), Firefox Beta (58.0b9) and the latest Nightly (59.0a1) build. I've opened the browser using a new profile, I've navigated to web.whatsapp.com page, selected a contact, written a message, pressed the "Enter" key and the message was sent without any problem encountered.

Can you please retest this issue on latest Beta build using a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/AR5o9d)?
Flags: needinfo?(luisccgoncalves)
Just retested it in firefox nightly 59.0a1 and the bug is still there (even with a new profile).
This does not happen in Firefox in Windows or in Chromium in the latest version of Ubuntu Mate.
Flags: needinfo?(luisccgoncalves)
Component: Untriaged → Desktop
Product: Firefox → Tech Evangelism
Thanks for the report. I'm also unable to reproduce this issue in Firefox 59 for Ubuntu with a fresh profile.
Why was this bug moved from Firefox to Tech Evangelism?
If there is a problem with standards in the whatsapp.com website, I can contact them. But I would like to point them in a specific direction.
In Tech Evangelism we try to work with the site to help resolve issues. With this particular report, we haven't been able to reproduce the issue which makes it difficult to diagnose and have a suggestion / direction for Whatsapp.

I downloaded Ubuntu Mate 16.04.3 today to see if it was OS related. But I still can't reproduce this issue in Firefox 58.
I have same issue on Linux with any version of firefox (either with default profile or a new one). Right now I have 61.0a1 (2018-03-12) (64-bit)
On macOS is working.
Hmm. I just tried in a fresh Ubuntu VM and on my main dev box, and both Enter keys are working fine.

I wonder if this might be related to a specific keyboard layout or locale, or maybe even some extra input method software?
How can I check this?

It is interesting that using the virtual keyboard it works.
The keyboard layout is English US
$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
That's also how my locale output appears (save for having no LANGUAGE= line).

Just in case, I wonder what the xev command outputs for your enter keys? For me, it shows these values:

>keycode 36 (keysym 0xff0d, Return)
>keycode 104 (keysym 0xff8d, KP_Enter)
KeyPress event, serial 37, synthetic NO, window 0x6400001,
    root 0x10c, subw 0x0, time 33168231, (138,598), root:(1000,1058),
    state 0x10, keycode 36 (keysym 0xff0d, Return), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
"   XmbLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x6400001,
    root 0x10c, subw 0x0, time 33168342, (138,598), root:(1000,1058),
    state 0x10, keycode 36 (keysym 0xff0d, Return), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x6400001,
    root 0x10c, subw 0x0, time 33169991, (138,598), root:(1000,1058),
    state 0x10, keycode 104 (keysym 0xff8d, KP_Enter), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
"   XmbLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x6400001,
    root 0x10c, subw 0x0, time 33170103, (138,598), root:(1000,1058),
    state 0x10, keycode 104 (keysym 0xff8d, KP_Enter), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False
That's essentially the same as what I see, so I'm not sure why you're getting different results in Firefox (I do see state 0x0 instead of 0x10, but I don't know whether that would affect this).

I'm guessing you don't see any suspicious errors or other messages in the devtools console log for the WhatsApp web tab (especially after pressing enter)?
I tried using Quantum and Nightly and at loading page I received these errors:
>Content Security Policy: Directive ‘child-src’ has been deprecated. Please use directive ‘worker-src’ to control workers, or directive ‘frame-src’ to control frames respectively.
>uncaught exception: No ServiceWorker controlling this client.
But other than this there is no other error on the console.

Safe mode has same behavior.
Then I'm afraid I'm stuck. I wonder if there's someone else we should ping for more ideas.. what do you think, :adamopenweb?
Maybe Masayuki can help?
Flags: needinfo?(masayuki)
Could you check what keydown/keypress/keyup events are fired on your environment?
https://w3c.github.io/uievents/tools/key-event-viewer.html
Flags: needinfo?(masayuki) → needinfo?(cezar)
https://pastebin.com/raw/e91ucaWJ
Flags: needinfo?(cezar)
Ah, is your symptom a recent regression? If so, this must have been fixed by bug 1443421. Unfortunately, that was backed out although it should've been fixed at same time as bug 1343451. Could you check it with new Nightly build?

However, this bug was reported 3 months ago. So, there may be different bug.
For me it is not a regression. I tried this on different versions of firefox: debian default esr version 52.6.0 (64-bit), quantum version (58.0.2) and nightly 61.0a1 (today's version).
Same issue with all of them. I don't have a problem with any version of firefox on Windows or macOS High Sierra.
Kernel version:
>$ uname -a
>Linux debian-ws 4.14.0-3-amd64 #1 SMP Debian 4.14.17-1 (2018-02-14) x86_64 GNU/Linux
Debian version (everything up-to-date):
>$ lsb_release -a
>No LSB modules are available.
>Distributor ID:	Debian
>Description:	Debian GNU/Linux testing (buster)
>Release:	testing
>Codename:	buster
Chromium/Chrome works on this machine, but it has different output:
https://pastebin.com/raw/c15jWPTG

If there is anything I could help, let me know.
After fixing bug 1443421, the odd keyboard events of #1, #4, #6 and #9 in comment 17 should be gone. Perhaps, next Nightly build must include the fix. Could you let me know the result of comment 16 with newer (perhaps, next?) Nightly build?
Flags: needinfo?(cezar)
Priority: -- → P3
https://pastebin.com/raw/JagVsCKj

It doesn't seem to be any change. Build id: 20180315223216 - I just upgraded to the latest nightly version.
Flags: needinfo?(cezar)
(In reply to cezar from comment #21)
> https://pastebin.com/raw/JagVsCKj
> 
> It doesn't seem to be any change. Build id: 20180315223216 - I just upgraded
> to the latest nightly version.

Hmm, that's really odd. The "Process" key events shouldn't be fired in this case. Which IM do you use? ibus, fcitx or uim? It seems that your environment isn't usual from a point of view of IME handling.

Perhaps, I need to check IMContextWrapper's log on your environment. If you don't mind, could you attach a log file which is created by the following steps?

1. Launch Nightly with following env:
MOZ_LOG=nsGtkIMModuleWidgets:5,sync
MOZ_LOG_FILE=~/nightly-ime.log
2. Open https://w3c.github.io/uievents/tools/key-event-viewer.html *without* key operation.
3. Set focus to the <input> field of the testcase.
4. Type "Enter" (not necessary to test numpad's Enter key).
5. Close Nightly only with mouse.
6. Attach the log file from this bug's "Attach File" link.

Note that the log file includes any keyboard input. So, do not type anything unnecessary keys, especially your private like passwords.
Flags: needinfo?(cezar)
Component: Desktop → Widget: Gtk
Keywords: inputmethod
OS: Unspecified → Linux
Product: Tech Evangelism → Core
Hardware: Unspecified → All
Version: unspecified → Trunk
I mean, we're dispatching wrong Enter key event redundantly. This is our bug caused by Linux's IME hell. On the other hand, I don't understand why web.whatsapp.com doesn't handle Enter key correctly with Enter keydown and keypress event (events whose key are not set to "Process" in comment 21). So, the website might have some bugs but I'm not sure since I don't have its account.
What '*without* key operation' means?
(In reply to cezar from comment #24)
> What '*without* key operation' means?

Please use mouse and context menus if you need to paste or something. Please avoid to include other key input into the log file.
I have another question. What keyboard events are fired in the testcase on Firefox 60 or earlier? Unfortunately, I changed a lot around the keyboard event dispatcher of Linux.
Attached file log_file_nightly.log — 
Nighlty firefox enter log
Flags: needinfo?(cezar)
Firefox 59 (Quantum) enter press log
Nightly key press - https://pastebin.com/raw/gLgwCVSg
Quantum (v59) key press - https://pastebin.com/raw/9TsZUspd
I installed debian from official *cinnamon*.iso image with the default settings.

It seems that is using IBus (I suppose because I can see the icon in the taskbar). Now that you asked, when I close it (right click - Quit) whatsapp is working and there is no additional key events:
https://pastebin.com/raw/QtQVwLrH
Attachment #8959537 - Attachment mime type: text/x-log → text/plain
Attachment #8959538 - Attachment mime type: text/x-log → text/plain
Thank you very much! The log said that your environment uses XIM as default IM. However, according to the actual key event handling of IME, it looks like ibus or fcitx actually works. And according to your comment 30, it may work fine if you launch Firefox/Nightly with GTK_IM_MODULE=ibus. But I think that we should be able to detect actual backend if default IM is XIM.

# But according to the 59's result in comment 29, I don't know why it won't work with 60 and earlier.
Status: UNCONFIRMED → NEW
Ever confirmed: true
GTK_IM_MODULE=ibus /tools/firefox-nightly/firefox does the trick

Thanks.
Now it's working without changing GTK_IM_MODULE.
https://pastebin.com/raw/YtFHNbEu
Flags: needinfo?(cezar)
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Comment on attachment 8960404 [details]
Bug 1423693 - Make IMContextWrapper::Init() resolve actual IM if active IM context ID is "xim" and there is XMODIFIERS env

https://reviewboard.mozilla.org/r/229182/#review234988
Attachment #8960404 - Flags: review?(m_kato) → review+
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/2013763dd2b6
Make IMContextWrapper::Init() resolve actual IM if active IM context ID is "xim" and there is XMODIFIERS env r=m_kato
https://hg.mozilla.org/mozilla-central/rev/2013763dd2b6
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox61: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
I've started using ibus since yesterday (had no ime before this) and found that pressing enter now does nothing while using ibus. Maybe not entirely fixed?
I can confirm now that upon exiting ibus, the enter key functionality becomes available again. Strangely, this is only a bug on web.whatsapp.com and not any other web app I've encountered.

Using 61.0 from the Ubuntu repository on Kubuntu.
I also confirm that when leaving ibus the enter key becomes available again. In my case the error occurred both in web.whatsapp.com and in the emails search bar of gmail.com.

Using Firefox 61.0.1 (64 bits) from the official repositories in Ubuntu Mate 18.04.1 LTS.
Please file a new bug with the log mentioned in comment 22 and value of GTK_IM_MODULE since this bug has already been fixed and a bug shouldn't treat another bug.
I can confirm this bug.

OS: Ubuntu Mate 18.04.1 LTS

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.
Depends on: 1498823
Well, this must be a really difficult bug to find (or fix or prioritize), because it remains alive across many versions.
I really like Firefox, but this bug is very annoying in WhatsApp web and Gmail search bar. Isn't there at least a workaround or an addon to cope with it?
Thanks!
(In reply to Daniel Sottile from comment #46)
> Well, this must be a really difficult bug to find (or fix or prioritize),
> because it remains alive across many versions.
> I really like Firefox, but this bug is very annoying in WhatsApp web and
> Gmail search bar. Isn't there at least a workaround or an addon to cope with
> it?
> Thanks!

please continue to bug 1498823.  We need know why this isn't fixed on the latest version.

I have got the same problem using Debian testing and firefox 60.4.0esr
I'm unable to send messages on Whatsapp Web since <enter> key seems not to work.

nolddor@computer:~$ localectl status

System Locale: LANG=es_ES.UTF-8
VC Keymap: n/a
X11 Layout: es
X11 Model: pc105

Same problem here when my keyboard layout is not English. I use Persian layout as my second language and when I'm typing Persian I can't send message with enter key. I can send by changing to English layout again. I use Google Chrome Version 71.0.3578.98 (Official Build) (64-bit).

Sorry for the inconvenience, however, I currently don't have a plan to port this bug, bug 1516323 nor bug 1498823.

RyanVM: Do you think that we should port them to ESR60? Debian 9.x uses ESR60 as their default browser, though.

Flags: needinfo?(ryanvm)

@navid.ei2008 is correct.

This bug is reproduced on Ubuntu 18.04 both in Chrome and FF, when the keyboard is not set to english.

Hello guys, i'm having the same problem on Debian 9.7 with Chrome, Chromium and Firefox...
Any suggestion?

Flags: needinfo?(ryanvm) → needinfo?(jcristau)

I can confirm that this behavior doesn't happen for me in FF anymore.
Only in Chrome.

On Debian 9.7 I removed the "Ibus" app and the problem was solved...

It appeared solved after FF release 65.0 with spanish keyboard distribution.
Thanks a lot.

If this + bug 1516323 + bug 1498823 were the full set of changes we'd need to make 60esr work better with ibus I guess that'd be ok. But trying it out I'm getting conflicts with at least bug 1443421 (the code changed in this bug seems to have been added there), so I'm not sure what's going on.

Flags: needinfo?(jcristau)

(In reply to Julien Cristau [:jcristau] from comment #56)

But trying it out I'm getting conflicts with at least bug 1443421 (the code changed in this bug seems to have been added there), so I'm not sure what's going on.

Ah, I forgot it. Unfortunately, it's actually required for the uplift (i.e., not simple conflict of the merge, actually depending on). Additionally, the fix is a preparation for some follow up patches (for fixing bug 354358). So, taking only it into ESR branch may break something. If drivers think that we should fix this on ESR branch even it becomes big patch, I'll try to write and test it, but I don't recommend it even though WhatsApp is a major service.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: