Emoji range encoded in JSON mangled #3727

Closed
pothibo opened this Issue Nov 22, 2011 · 36 comments

Comments

Projects
None yet
@pothibo
Contributor

pothibo commented Nov 22, 2011

I'm receiving emoji from an iOS device. Everything is fine from there (using the console I can verify that the right emoji is stored in postgresql)

Now, when I want to retrieve it via json on my iOS device, the emoji are not the proper one. I did some testing in irb and here's what I came up with:

irb(main):047:0> test = {"emoji" => "\u{1F618}"}
=> {"emoji"=>"\u{1F618}"}
irb(main):048:0> test = MultiJson::Engines::JsonGem.encode(test)
=> "{\"emoji\":\"\\uf618\"}"
irb(main):049:0> test
=> "{\"emoji\":\"\\uf618\"}"
irb(main):050:0> test = MultiJson::Engines::JsonGem.decode(test)
=> {"emoji"=>""}

Since I'm new to Unicode encoding/decoding, my assumptions could be wrong.

From what I can understand from ActiveSupport::JSON::Encoding.escape, the encode method change the annotation to clean UTF-7. Doing so change the character value once decoded. I do understand the issues with UTF-7 and XSS, but is it possible to have something that returns valid UTF-8 code in the emoji's range while keeping the security?

@pothibo

This comment has been minimized.

Show comment
Hide comment
@pothibo

pothibo Nov 23, 2011

Contributor

After a bit of debugging (I was unfamiliar with pack() and unpack() method and the JSON standard in general, so I had to dig a bit), I came to understand that the escape method does different packing things.

However, the JSON standard allow you to pass "any" unicode character to the JSON value. So why is this encoder, encodes the string to support only the \uxxxx notation when passing the whole unicode string would be good enough in the first place?

Contributor

pothibo commented Nov 23, 2011

After a bit of debugging (I was unfamiliar with pack() and unpack() method and the JSON standard in general, so I had to dig a bit), I came to understand that the escape method does different packing things.

However, the JSON standard allow you to pass "any" unicode character to the JSON value. So why is this encoder, encodes the string to support only the \uxxxx notation when passing the whole unicode string would be good enough in the first place?

@dbackeus

This comment has been minimized.

Show comment
Hide comment
@dbackeus

dbackeus Dec 1, 2011

Also broken are Osmanyan characters (used for the Somali language) added in Unicode 6.0. As they use 5 hex-characters rather than 4. And even if the escaping would return the correct 5-hex value it would not be unescaped correctly in Javascript.

"\U+10488".to_json # "\"\\u0488\""

I'm currently employing a monkey patch that removes the ascii-fication stuff. From what I can see everything works just fine. Which makes sense as the whole stack is UTF-8 compatible.

module ActiveSupport::JSON::Encoding
  class << self
    def escape(string)
      if string.respond_to?(:force_encoding)
        string = string.encode(::Encoding::UTF_8, :undef => :replace).force_encoding(::Encoding::BINARY)
      end
      json = string.gsub(escape_regex) { |s| ESCAPED_CHARS[s] }
      json = %("#{json}")
      json.force_encoding(::Encoding::UTF_8) if json.respond_to?(:force_encoding)
      json
    end
  end
end

You mentioned security issues. Where can I read up on that? Would my patch be subject to vulnerability?

If the ascii conversion is not even fully unicode compatible it seems to me it should not be used by default or at least I should be able to opt out of it.

If anyone wants to test the osmanya stuff it might be helpful to install a compatible font like the free Andagi font found on this page: http://www.i18nguy.com/unicode/unicode-font.html

dbackeus commented Dec 1, 2011

Also broken are Osmanyan characters (used for the Somali language) added in Unicode 6.0. As they use 5 hex-characters rather than 4. And even if the escaping would return the correct 5-hex value it would not be unescaped correctly in Javascript.

"\U+10488".to_json # "\"\\u0488\""

I'm currently employing a monkey patch that removes the ascii-fication stuff. From what I can see everything works just fine. Which makes sense as the whole stack is UTF-8 compatible.

module ActiveSupport::JSON::Encoding
  class << self
    def escape(string)
      if string.respond_to?(:force_encoding)
        string = string.encode(::Encoding::UTF_8, :undef => :replace).force_encoding(::Encoding::BINARY)
      end
      json = string.gsub(escape_regex) { |s| ESCAPED_CHARS[s] }
      json = %("#{json}")
      json.force_encoding(::Encoding::UTF_8) if json.respond_to?(:force_encoding)
      json
    end
  end
end

You mentioned security issues. Where can I read up on that? Would my patch be subject to vulnerability?

If the ascii conversion is not even fully unicode compatible it seems to me it should not be used by default or at least I should be able to opt out of it.

If anyone wants to test the osmanya stuff it might be helpful to install a compatible font like the free Andagi font found on this page: http://www.i18nguy.com/unicode/unicode-font.html

@pothibo

This comment has been minimized.

Show comment
Hide comment
@pothibo

pothibo Dec 1, 2011

Contributor

Well, I think it's secured. but I cannot be sure why people are using the \u notation when it truncates the UTF-8 encoding to 4bytes. Maybe it's a bandwidth issue they had in mind. I have also monkey patched my code to support native UTF-8 instead of the \u notation.

Contributor

pothibo commented Dec 1, 2011

Well, I think it's secured. but I cannot be sure why people are using the \u notation when it truncates the UTF-8 encoding to 4bytes. Maybe it's a bandwidth issue they had in mind. I have also monkey patched my code to support native UTF-8 instead of the \u notation.

@jasongregori

This comment has been minimized.

Show comment
Hide comment
@jasongregori

jasongregori Jan 31, 2012

Just added @dbackeus's patch to our project and it works great. Is there any reason this doesn't get merged into rails?

For any others that find this discussion, here is the logic (it wasn't clear to me, this as best as I understand it).

When converting a string to json as_json will convert a certain range of characters to the \u format. The \u format in json only officially supports characters with at most 4 bytes in them. You can use \u with more bytes but it isn't in the spec and won't work with all parsers. I think rails converts these characters for security reasons (not sure what security reasons). A lot of iOS emoji (and apparently Osmanyan) characters are 5 bytes. as_json seems to not consider this possibility and converts those incorrectly. (For example "\u{1F485}" becomes "\uf485" losing the 1).

@dbackeus's patch just removes the lines that do this:

      json = string.
        gsub(escape_regex) { |s| ESCAPED_CHARS[s] }.
        gsub(/([\xC0-\xDF][\x80-\xBF]|
               [\xE0-\xEF][\x80-\xBF]{2}|
               [\xF0-\xF7][\x80-\xBF]{3})+/nx) { |s|
        s.unpack("U*").pack("N*").unpack("H*")[0].gsub(/.{4}/n, '\\\\u\&')
      }

Just added @dbackeus's patch to our project and it works great. Is there any reason this doesn't get merged into rails?

For any others that find this discussion, here is the logic (it wasn't clear to me, this as best as I understand it).

When converting a string to json as_json will convert a certain range of characters to the \u format. The \u format in json only officially supports characters with at most 4 bytes in them. You can use \u with more bytes but it isn't in the spec and won't work with all parsers. I think rails converts these characters for security reasons (not sure what security reasons). A lot of iOS emoji (and apparently Osmanyan) characters are 5 bytes. as_json seems to not consider this possibility and converts those incorrectly. (For example "\u{1F485}" becomes "\uf485" losing the 1).

@dbackeus's patch just removes the lines that do this:

      json = string.
        gsub(escape_regex) { |s| ESCAPED_CHARS[s] }.
        gsub(/([\xC0-\xDF][\x80-\xBF]|
               [\xE0-\xEF][\x80-\xBF]{2}|
               [\xF0-\xF7][\x80-\xBF]{3})+/nx) { |s|
        s.unpack("U*").pack("N*").unpack("H*")[0].gsub(/.{4}/n, '\\\\u\&')
      }
@pothibo

This comment has been minimized.

Show comment
Hide comment
@pothibo

pothibo Jan 31, 2012

Contributor

JSON support UTF-8 as-is. If you remove the \u notation alltogether in your JSON implementation, everything will work fine.

EDIT: Oops nevermind what I wrote. You did exactly what I just said. I just woke up, haven't had my coffee yet.

Contributor

pothibo commented Jan 31, 2012

JSON support UTF-8 as-is. If you remove the \u notation alltogether in your JSON implementation, everything will work fine.

EDIT: Oops nevermind what I wrote. You did exactly what I just said. I just woke up, haven't had my coffee yet.

@jasongregori

This comment has been minimized.

Show comment
Hide comment
@jasongregori

jasongregori Jan 31, 2012

no worries :)
Thats what I'm wondering. Why do they have that code in there? Can we merge this patch?

no worries :)
Thats what I'm wondering. Why do they have that code in there? Can we merge this patch?

@pothibo

This comment has been minimized.

Show comment
Hide comment
@pothibo

pothibo Jan 31, 2012

Contributor

I wish they would... but haven't heard from the ruby guys.... Probably a low priority issue...

Contributor

pothibo commented Jan 31, 2012

I wish they would... but haven't heard from the ruby guys.... Probably a low priority issue...

@jasongregori

This comment has been minimized.

Show comment
Hide comment
@jasongregori

jasongregori Feb 1, 2012

yeah, that sucks. i mean emoji is kind of for fun but to have your language not work like @dbackeus seems like a pretty high priority.

yeah, that sucks. i mean emoji is kind of for fun but to have your language not work like @dbackeus seems like a pretty high priority.

@dazuiba

This comment has been minimized.

Show comment
Hide comment
@dazuiba

dazuiba Feb 10, 2012

json-gem(http://flori.github.com/json") does have this bug.

But it does not play well with rails 3.1

It seems like that you cannot config action-pack render json with json-gem solution.

dazuiba commented Feb 10, 2012

json-gem(http://flori.github.com/json") does have this bug.

But it does not play well with rails 3.1

It seems like that you cannot config action-pack render json with json-gem solution.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Apr 30, 2012

Member

Is this still a problem today? Encodings: :(

Member

steveklabnik commented Apr 30, 2012

Is this still a problem today? Encodings: :(

@dazuiba

This comment has been minimized.

Show comment
Hide comment
@dazuiba

dazuiba Apr 30, 2012

the patch brough by @dbackeus does solve this problem. for me.

@steveklabnik does your database(server/client/mysql2 gem) already support utf8mb4? if not may be you should make that ok first.

dazuiba commented Apr 30, 2012

the patch brough by @dbackeus does solve this problem. for me.

@steveklabnik does your database(server/client/mysql2 gem) already support utf8mb4? if not may be you should make that ok first.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Apr 30, 2012

Member

You're still using the monkey patch? I'm wondering if it was fixed anywhere in a release. Trying to go through and close out old issues if they got fixed somewhere else.

Member

steveklabnik commented Apr 30, 2012

You're still using the monkey patch? I'm wondering if it was fixed anywhere in a release. Trying to go through and close out old issues if they got fixed somewhere else.

@dbackeus

This comment has been minimized.

Show comment
Hide comment
@dbackeus

dbackeus Apr 30, 2012

Still have to use the patch. Also still haven't seen any clear explanation why the escaping is done in the first place. Backwards compatibility with badly configured legacy systems?

As Rails is a modern web stack expecting UTF-8 all over the place this kind of hacking should not be necessary!

Still have to use the patch. Also still haven't seen any clear explanation why the escaping is done in the first place. Backwards compatibility with badly configured legacy systems?

As Rails is a modern web stack expecting UTF-8 all over the place this kind of hacking should not be necessary!

@andreychernih

This comment has been minimized.

Show comment
Hide comment
@andreychernih

andreychernih Apr 30, 2012

Contributor

I can confirm that issue still exists because of automatically escaped characters in JSON. I am using monkey patch for workaround.

Contributor

andreychernih commented Apr 30, 2012

I can confirm that issue still exists because of automatically escaped characters in JSON. I am using monkey patch for workaround.

@jasongregori

This comment has been minimized.

Show comment
Hide comment
@jasongregori

jasongregori Apr 30, 2012

please add this to rails so we don't have to all use patches!

please add this to rails so we don't have to all use patches!

@pothibo

This comment has been minimized.

Show comment
Hide comment
@pothibo

pothibo Jun 21, 2012

Contributor

Apparently this is very low on their priority list :/

Contributor

pothibo commented Jun 21, 2012

Apparently this is very low on their priority list :/

@fbjork

This comment has been minimized.

Show comment
Hide comment
@fbjork

fbjork Jul 27, 2012

Any update on this getting fixed in Rails?

fbjork commented Jul 27, 2012

Any update on this getting fixed in Rails?

@masterkain

This comment has been minimized.

Show comment
Hide comment
@masterkain

masterkain Aug 21, 2012

Contributor

news?

Contributor

masterkain commented Aug 21, 2012

news?

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Aug 21, 2012

Member

Rails is run by volunteers, if nobody writes a patch, things sit here until someone finds the time.

If anyone would like to contribute a patch, that'd be great. :)

Member

steveklabnik commented Aug 21, 2012

Rails is run by volunteers, if nobody writes a patch, things sit here until someone finds the time.

If anyone would like to contribute a patch, that'd be great. :)

@zbskii

This comment has been minimized.

Show comment
Hide comment
@zbskii

zbskii Aug 22, 2012

Contributor

Made a patch for master and 3.1.

Note that on master, there are a bunch of multibyte unicode tests failing in activesupport that were failing before I made my patch.

The issue here is only with unicode characters > 0xFFFF. Rails converts all JSON unicode characters to the escaped \uXXXX form, but there was a bug with this code for character not on the BMP - anything over 0xFFFF. These need to be encoding in 'surrogate pairs' as this is the weird and wacky way Javascript handles 4 byte characters. See: http://mathiasbynens.be/notes/javascript-encoding

Contributor

zbskii commented Aug 22, 2012

Made a patch for master and 3.1.

Note that on master, there are a bunch of multibyte unicode tests failing in activesupport that were failing before I made my patch.

The issue here is only with unicode characters > 0xFFFF. Rails converts all JSON unicode characters to the escaped \uXXXX form, but there was a bug with this code for character not on the BMP - anything over 0xFFFF. These need to be encoding in 'surrogate pairs' as this is the weird and wacky way Javascript handles 4 byte characters. See: http://mathiasbynens.be/notes/javascript-encoding

@tenderlove

This comment has been minimized.

Show comment
Hide comment
@tenderlove

tenderlove Aug 22, 2012

Member

Anyone know why we're converting these to the '\u' notation at all? From what I can tell in the JSON spec, any valid unicode character is fine. It seems like we could just remove this gsub all together?

/cc @wycats @josevalim @jeremy

Member

tenderlove commented Aug 22, 2012

Anyone know why we're converting these to the '\u' notation at all? From what I can tell in the JSON spec, any valid unicode character is fine. It seems like we could just remove this gsub all together?

/cc @wycats @josevalim @jeremy

@wycats

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Aug 22, 2012

Member

The correct way to encode a UTF-8 character in JSON is... UTF-8[1]! JavaScript doesn't support escape sequences for unicode characters outside the BMP[2], but it doesn't support documents encoded in UTF-8, so rather than some rube goldberg attempt to encode using escape sequences, just use dump the UTF-8 bytes and call it a day.

[1] http://json.org/
[2] http://stackoverflow.com/questions/3744721/javascript-strings-outside-of-the-bmp

Member

wycats commented Aug 22, 2012

The correct way to encode a UTF-8 character in JSON is... UTF-8[1]! JavaScript doesn't support escape sequences for unicode characters outside the BMP[2], but it doesn't support documents encoded in UTF-8, so rather than some rube goldberg attempt to encode using escape sequences, just use dump the UTF-8 bytes and call it a day.

[1] http://json.org/
[2] http://stackoverflow.com/questions/3744721/javascript-strings-outside-of-the-bmp

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Sep 15, 2012

Member

The great @wycats has spoken. Just Use Unicode(tm) :D

Member

steveklabnik commented Sep 15, 2012

The great @wycats has spoken. Just Use Unicode(tm) :D

@dbackeus

This comment has been minimized.

Show comment
Hide comment
@dbackeus

dbackeus Dec 13, 2012

Why was this closed?

The monkey patch to "just use unicode" is still needed - Rails was never fixed.

All that needs to be done according to my understanding is remove the gsubs like in my patch mentioned above.

Is that agreed on? Should I make a pull request?

Seems like anyone with commit rights could remove those lines easily enough...

Why was this closed?

The monkey patch to "just use unicode" is still needed - Rails was never fixed.

All that needs to be done according to my understanding is remove the gsubs like in my patch mentioned above.

Is that agreed on? Should I make a pull request?

Seems like anyone with commit rights could remove those lines easily enough...

@pothibo

This comment has been minimized.

Show comment
Hide comment
@pothibo

pothibo Dec 13, 2012

Contributor

@dbackeus well, I have the same feeling. I was using Unicode. It's rails that is unpacking the utf-8 string and using the escape sequences.

The code snippet in the issue description is to demonstrate rails behavior.

Contributor

pothibo commented Dec 13, 2012

@dbackeus well, I have the same feeling. I was using Unicode. It's rails that is unpacking the utf-8 string and using the escape sequences.

The code snippet in the issue description is to demonstrate rails behavior.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Dec 13, 2012

Member

I may have mis-closed it.

Can you give me a Really Simple Reproduction? It's been a long time. If there's still a real bug here, I'll apply a patch.

Member

steveklabnik commented Dec 13, 2012

I may have mis-closed it.

Can you give me a Really Simple Reproduction? It's been a long time. If there's still a real bug here, I'll apply a patch.

@pothibo

This comment has been minimized.

Show comment
Hide comment
@pothibo

pothibo Dec 13, 2012

Contributor

Sorry, it took a bit longer than expected, I had to browse the code since it's been so long ago :)

#encoding: utf-8
require 'test_helper'

class UTF8Test < ActiveSupport::TestCase
  test "escaping_utf8_strings" do
    @hash = {"text" => ""}

    @json = ActiveSupport::JSON.encode(@hash)
    @decoded_hash = ActiveSupport::JSON.decode(@json)
    assert_equal(@decoded_hash["text"], "")
  end
end

In this example, this isn't empty string in @hash... and assert_equal... it's an actual emoji. If you can't paste it properly, I suggest you replace the string with an emoji of your own (Obviously, it needs to be an emoji i.e > 0xFFFF)

This fails on rails 3.2.9

Contributor

pothibo commented Dec 13, 2012

Sorry, it took a bit longer than expected, I had to browse the code since it's been so long ago :)

#encoding: utf-8
require 'test_helper'

class UTF8Test < ActiveSupport::TestCase
  test "escaping_utf8_strings" do
    @hash = {"text" => ""}

    @json = ActiveSupport::JSON.encode(@hash)
    @decoded_hash = ActiveSupport::JSON.decode(@json)
    assert_equal(@decoded_hash["text"], "")
  end
end

In this example, this isn't empty string in @hash... and assert_equal... it's an actual emoji. If you can't paste it properly, I suggest you replace the string with an emoji of your own (Obviously, it needs to be an emoji i.e > 0xFFFF)

This fails on rails 3.2.9

@pothibo

This comment has been minimized.

Show comment
Hide comment
@pothibo

pothibo Dec 13, 2012

Contributor

Ok. Github doesn't allow emoji range string in the textbox. So you have to add an emoji character yourself, sorry about that.

Contributor

pothibo commented Dec 13, 2012

Ok. Github doesn't allow emoji range string in the textbox. So you have to add an emoji character yourself, sorry about that.

@dbackeus

This comment has been minimized.

Show comment
Hide comment
@dbackeus

dbackeus Dec 13, 2012

Thanks for the test - I finally got around to adding a spec for the monkey patch in our application. Which fails if I remove the monkey patch.

I put it up as a gist here: https://gist.github.com/4278031

Looks like gist accepted the high bit character as well. Though you'll need to install the andagii font to view it properly: http://www.i18nguy.com/unicode/andagii.zip

Thanks for the test - I finally got around to adding a spec for the monkey patch in our application. Which fails if I remove the monkey patch.

I put it up as a gist here: https://gist.github.com/4278031

Looks like gist accepted the high bit character as well. Though you'll need to install the andagii font to view it properly: http://www.i18nguy.com/unicode/andagii.zip

@steveklabnik steveklabnik reopened this Dec 13, 2012

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Dec 13, 2012

Member

I will look at this soon, thank you.

Member

steveklabnik commented Dec 13, 2012

I will look at this soon, thank you.

@zbskii

This comment has been minimized.

Show comment
Hide comment
@zbskii

zbskii Dec 14, 2012

Contributor

I have a patch for this here against master: zbskii@9ace3a8

Somehow I've broken @github and it won't let me submit a pull request.

Contributor

zbskii commented Dec 14, 2012

I have a patch for this here against master: zbskii@9ace3a8

Somehow I've broken @github and it won't let me submit a pull request.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Dec 14, 2012

Member

@zbskii that patch looks great, and seems consistent with both @wycats and @tenderlove 's comments. As a new commiter though, I want to double check with someone else before I apply it.

@pixeltrix ? @tenderlove ? @wycats ?

Member

steveklabnik commented Dec 14, 2012

@zbskii that patch looks great, and seems consistent with both @wycats and @tenderlove 's comments. As a new commiter though, I want to double check with someone else before I apply it.

@pixeltrix ? @tenderlove ? @wycats ?

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Dec 14, 2012

Member

Sweet, @tenderlove gave me a 👍. Thank you @zbskii !!! ❤️

Member

steveklabnik commented Dec 14, 2012

Sweet, @tenderlove gave me a 👍. Thank you @zbskii !!! ❤️

@zbskii

This comment has been minimized.

Show comment
Hide comment
@zbskii

zbskii Dec 15, 2012

Contributor

Can we get some 3.x backport love on this too? Should I just add a patch for that as well?

Contributor

zbskii commented Dec 15, 2012

Can we get some 3.x backport love on this too? Should I just add a patch for that as well?

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Dec 15, 2012

Member

Since this is a bugfix, yes, it's eligible for backport. Done in 815a943, there was only a teeny bit of conflict due to 1.8 stuff.

Member

steveklabnik commented Dec 15, 2012

Since this is a bugfix, yes, it's eligible for backport. Done in 815a943, there was only a teeny bit of conflict due to 1.8 stuff.

jturkel referenced this issue in nanma80/json-stream Oct 14, 2013

gwprice pushed a commit to edx/cs_comments_service that referenced this issue Dec 16, 2013

Greg Price
Add tests for non-ASCII characters in comments
Due to a bug[1] in ActiveRecord's JSON serialization, tests for characters
outside the BMP are marked as pending.

[1]: rails/rails#3727

gwprice pushed a commit to edx/cs_comments_service that referenced this issue Dec 16, 2013

Greg Price
Add tests for non-ASCII characters in comments
Due to a bug[1] in ActiveRecord's JSON serialization, tests for characters
outside the BMP are marked as pending.

[1]: rails/rails#3727

gwprice pushed a commit to edx/cs_comments_service that referenced this issue Dec 18, 2013

Greg Price
Add tests for non-ASCII characters in comments
Due to a bug[1] in ActiveRecord's JSON serialization, tests for characters
outside the BMP are marked as pending.

[1]: rails/rails#3727

@janraasch janraasch referenced this issue in markevans/dragonfly-s3_data_store Nov 20, 2014

Open

Excon::Errors::Forbidden with files containing Umlauts #6

toddmazierski pushed a commit to lolibrarian/nypl-tweetwall that referenced this issue Aug 3, 2016

@LouieGeetoo

This comment has been minimized.

Show comment
Hide comment
@LouieGeetoo

LouieGeetoo Nov 10, 2017

For anyone still on Rails 3.2 who comes across this: the fix was backported, but then it was reverted because the change in behavior caused problems for some as described in #9498.

At least for me, @dbackeus's monkey-patch in #3727 (comment) still did the trick.

LouieGeetoo commented Nov 10, 2017

For anyone still on Rails 3.2 who comes across this: the fix was backported, but then it was reverted because the change in behavior caused problems for some as described in #9498.

At least for me, @dbackeus's monkey-patch in #3727 (comment) still did the trick.

@Exact1990 Exact1990 referenced this issue in rpush/rpush May 3, 2018

Closed

FCM && Emoji #432

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment