fb-mac-messenger
fb-mac-messenger copied to clipboard
Characters entered with Emoji & Symbols dialog disappear
This doesn't seem to happen on messenger.com, so I think it's a problem with Mac Messenger.

I have the same issue. Also happens when you type ":)" and then it's converted to an emoji symbol, then disappears.
I am having the same issue. Have been having it for a little bit. Also can confirm that messenger.com does not do this
This started happening to me when I updated to the OS X 10.11.4 public beta. Before that update it was fine. Is anyone else on the beta?
Not me, 10.11.2.
I've also noticed that if you drag the special characters popup and "tear it off" the text field so that it persists, the input works fine.
I am also on 10.11.2 and @mmontag is correct that if you "tear away" the popup, you can enter characters fine.
And this works for you in messenger.com in Safari? I'm on 10.11.3 and can't reproduce on any of my macs. Happy to reopen if someone can reliably reproduce this and point to this being a bug in this app and not messenger.com.
I can reproduce this. Emoji input works fine in Safari on messenger.com, but it doesn't work (unless "torn away") in the app. Using the 10.11.4 public beta.
Hmm, I can still reproduce after upgrading from 10.11.2 to 10.11.3. It does work in messenger.com in Safari.
I built locally and commented out all of main.js, and that didn't seem to help.
@mmontag This might be an issue with legacy WebView. Soon we will migrate to WKWebView, which is massively better than WebView.
If someone experiencing these issues can try the following, it would really help:
- make a new mac app
- put a WKWebView in it and load messenger.com
- investigate how/if this emoji panel works
That could either provide more ammunition for transitioning to WKWebView, or unearth some different issue.
This seems to be fixed in the latest version for me: 0.1.6.1455039740 using OSX 10.11.3.
@nzjoel Good to hear. @joshvickerson @mmontag @mcescalante Did the 0.1.6 release fix it for you?
I'm still seeing the same issue... I'm on 10.11.2 though:

Hoping to dig into this a bit more later today
Weird. Do you have spell checking enabled? Automatic spell checking? Any options like those that might trigger the behavior? Also, if someone wants to look into this, you want to see if app/main.js is doing anything funky. There have been so many patches (from PRs) to main.js that I don't know what's really going on anymore.
I am still having this problem with the 0.1.6 release (OS X 10.11.4 beta 3).
Good call @rsms. I created a dummy app with WKWebView at www.messenger.com, and it works fine. Replaced with WebView, and I get the disappearing behavior.
@mmontag Great find! Then this is definitely something that we'll punt on fixing until the WKWebView refactoring.
For context: WKWebView is great in many ways, but it does not allow direct memory bridging of JS-land and native space, which the current implementation depends on, mainly for desktop notifications. We'd first need to (re)write (i.e. come up with) a new solution for exposing our implementation of window.Notification in the webview.
Still getting this problem
I too am seeing this issue. In the meantime, a useful workaround this issue while we wait for the WKWebView refactor to happen, you can press the top right button that will expand the Emoji Window

and from there you can select the emoji. In fact, if you minimise the window after enlarging it, you can use emoji from when it's small (however, then if you close it, it will revert back to the normal behaviour - so best to keep it expanded)
Somewhat less of an issue now that we get a built-in emoji panel.

But still; no thinking 🤔, no tacos 🌮,, and no keyword search.
Also reported in #287 Reopening since it seems some people still have an issue with this.
No idea why this shouldn't work in Messenger for Mac 0.1.10 — it's definitely an issue with the web app messenger.com which this app wraps. Further, the message composer of messenger.com is implemented in a fairly complicated way where text input does not go into an input field, but is interpreted via key event listeners in the HTML DOM, which has in the past caused some other issues for this app (like OS alert beep/ping sound on first character typed, because WebKit's WebView thought it wasn't possible to type there (so it caused the system to play the alert sound.) I suspect this is due to a similar issue.