(In reply to Magnus Melin [:mkmelin] from comment #50) > What properties is it that cause a problem? I'm assuming they just have a wrong string type. Don't know which "properties" cause a the problem and don't really even know what you mean by "property". I can tell that the problem occurs at two places where JS_EncodeStringToBuffer() is called here https://searchfox.org/comm-central/rev/8dc57157bf7ae35ddd1882bb23e48fe11abc29b5/mozilla/js/xpconnect/src/XPCConvert.cpp#604 and here https://searchfox.org/comm-central/rev/8dc57157bf7ae35ddd1882bb23e48fe11abc29b5/mozilla/js/xpconnect/src/XPCConvert.cpp#726 The first call at line 604 is for string types: case nsXPTType::T_CHAR_STR: case nsXPTType::T_PSTRING_SIZE_IS: The other call at line 726 is for string type: case nsXPTType::T_CSTRING: In both cases the problem occurs when a UTF16 string is converted to a byte (UTF8) string and the upper byte is discarded. My fix is to keep the upper byte by decoding it in a different way (only if new parameter "losses" is true). Apparently with mozilla losses are never expected. With TB losses now only occur because folder names at this point are in UTF-16 and, with UTF8=ACCEPT active both byte are significant. With just mUTF7, the upper byte is always zero so no problem occurs. The actual discard/loss of the upper byte occurs here when decoding 2-byte char strings:https://searchfox.org/comm-central/rev/8dc57157bf7ae35ddd1882bb23e48fe11abc29b5/mozilla/js/src/jsapi.cpp#4538 I really have no idea what controls this. But I see this code occur in conjunction with a when a message in a UTF8 encoded folder name with non-latin1 chars (>U+00FF) is accessed and it has attachments inline. It occurs after the full message is fetched and after the inline parts are accessed from offline store or ram cache depending on configuration.
Bug 1571672 Comment 51 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Magnus Melin [:mkmelin] from comment #50) > What properties is it that cause a problem? I'm assuming they just have a wrong string type. Don't know which "properties" cause a the problem and don't really even know what you mean by "property". I can tell that the problem occurs at two places where JS_EncodeStringToBuffer() is called here https://searchfox.org/comm-central/rev/8dc57157bf7ae35ddd1882bb23e48fe11abc29b5/mozilla/js/xpconnect/src/XPCConvert.cpp#604 and here https://searchfox.org/comm-central/rev/8dc57157bf7ae35ddd1882bb23e48fe11abc29b5/mozilla/js/xpconnect/src/XPCConvert.cpp#726 Edit: Permalinks not working currently. Replace rev/<long number> with source The first call at line 604 is for string types: case nsXPTType::T_CHAR_STR: case nsXPTType::T_PSTRING_SIZE_IS: The other call at line 726 is for string type: case nsXPTType::T_CSTRING: In both cases the problem occurs when a UTF16 string is converted to a byte (UTF8) string and the upper byte is discarded. My fix is to keep the upper byte by decoding it in a different way (only if new parameter "losses" is true). Apparently with mozilla losses are never expected. With TB losses now only occur because folder names at this point are in UTF-16 and, with UTF8=ACCEPT active both byte are significant. With just mUTF7, the upper byte is always zero so no problem occurs. The actual discard/loss of the upper byte occurs here when decoding 2-byte char strings:https://searchfox.org/comm-central/rev/8dc57157bf7ae35ddd1882bb23e48fe11abc29b5/mozilla/js/src/jsapi.cpp#4538 I really have no idea what controls this. But I see this code occur in conjunction with a when a message in a UTF8 encoded folder name with non-latin1 chars (>U+00FF) is accessed and it has attachments inline. It occurs after the full message is fetched and after the inline parts are accessed from offline store or ram cache depending on configuration.
(In reply to Magnus Melin [:mkmelin] from comment #50) > What properties is it that cause a problem? I'm assuming they just have a wrong string type. Don't know which "properties" cause the problem and don't really even know what you mean by "property". I can tell that the problem occurs at two places where JS_EncodeStringToBuffer() is called here https://searchfox.org/comm-central/rev/8dc57157bf7ae35ddd1882bb23e48fe11abc29b5/mozilla/js/xpconnect/src/XPCConvert.cpp#604 and here https://searchfox.org/comm-central/rev/8dc57157bf7ae35ddd1882bb23e48fe11abc29b5/mozilla/js/xpconnect/src/XPCConvert.cpp#726 Edit: Permalinks not working currently for some reason. Replace "rev/<long number>" with "source" does work. The first call at line 604 is for string types: case nsXPTType::T_CHAR_STR: case nsXPTType::T_PSTRING_SIZE_IS: The other call at line 726 is for string type: case nsXPTType::T_CSTRING: In both cases the problem occurs when a UTF16 string is converted to a byte (UTF8) string and the upper byte is discarded. My fix is to keep the upper byte by decoding it in a different way (only if new parameter "losses" is true). Apparently with mozilla losses are never expected. With TB losses now only occur because folder names at this point are in UTF-16 and, with UTF8=ACCEPT active both byte are significant. With just mUTF7, the upper byte is always zero so no problem occurs. The actual discard/loss of the upper byte occurs here when decoding 2-byte char strings:https://searchfox.org/comm-central/rev/8dc57157bf7ae35ddd1882bb23e48fe11abc29b5/mozilla/js/src/jsapi.cpp#4538 I really have no idea what controls this. But I see this code occur in conjunction with a when a message in a UTF8 encoded folder name with non-latin1 chars (>U+00FF) is accessed and it has attachments inline. It occurs after the full message is fetched and after the inline parts are accessed from offline store or ram cache depending on configuration.
(In reply to Magnus Melin [:mkmelin] from comment #50) > What properties is it that cause a problem? I'm assuming they just have a wrong string type. Don't know which "properties" cause the problem and don't really even know what you mean by "property". I can tell that the problem occurs at two places where JS_EncodeStringToBuffer() is called here https://searchfox.org/comm-central/source/mozilla/js/xpconnect/src/XPCConvert.cpp#604 and here https://searchfox.org/comm-central/source/mozilla/js/xpconnect/src/XPCConvert.cpp#726 Edit: Permalinks not working currently for some reason. Replaced "rev/<long number>" with "source" now works. No idea why? The first call at line 604 is for string types: case nsXPTType::T_CHAR_STR: case nsXPTType::T_PSTRING_SIZE_IS: The other call at line 726 is for string type: case nsXPTType::T_CSTRING: In both cases the problem occurs when a UTF16 string is converted to a byte (UTF8) string and the upper byte is discarded. My fix is to keep the upper byte by decoding it in a different way (only if new parameter "losses" is true). Apparently with mozilla losses are never expected. With TB losses now only occur because folder names at this point are in UTF-16 and, with UTF8=ACCEPT active both byte are significant. With just mUTF7, the upper byte is always zero so no problem occurs. The actual discard/loss of the upper byte occurs here when decoding 2-byte char strings:https://searchfox.org/comm-central/source/mozilla/js/src/jsapi.cpp#4538 I really have no idea what controls this. But I see this code occur in conjunction with a when a message in a UTF8 encoded folder name with non-latin1 chars (>U+00FF) is accessed and it has attachments inline. It occurs after the full message is fetched and after the inline parts are accessed from offline store or ram cache depending on configuration.
(In reply to Magnus Melin [:mkmelin] from comment #50) > What properties is it that cause a problem? I'm assuming they just have a wrong string type. Don't know which "properties" cause the problem and don't really even know what you mean by "property". I can tell that the problem occurs at two places where JS_EncodeStringToBuffer() is called here https://searchfox.org/comm-central/source/mozilla/js/xpconnect/src/XPCConvert.cpp#605 and here https://searchfox.org/comm-central/source/mozilla/js/xpconnect/src/XPCConvert.cpp#727 Edit: Permalinks not working currently for some reason. Replaced "rev/<long number>" with "source" now works. No idea why? The first call at line 604 is for string types: case nsXPTType::T_CHAR_STR: case nsXPTType::T_PSTRING_SIZE_IS: The other call at line 726 is for string type: case nsXPTType::T_CSTRING: In both cases the problem occurs when a UTF16 string is converted to a byte (UTF8) string and the upper byte is discarded. My fix is to keep the upper byte by decoding it in a different way (only if new parameter "losses" is true). Apparently with mozilla losses are never expected. With TB losses now only occur because folder names at this point are in UTF-16 and, with UTF8=ACCEPT active both byte are significant. With just mUTF7, the upper byte is always zero so no problem occurs. The actual discard/loss of the upper byte occurs here when decoding 2-byte char strings:https://searchfox.org/comm-central/source/mozilla/js/src/jsapi.cpp#4532 I really have no idea what controls this. But I see this code occur in conjunction with a when a message in a UTF8 encoded folder name with non-latin1 chars (>U+00FF) is accessed and it has attachments inline. It occurs after the full message is fetched and after the inline parts are accessed from offline store or ram cache depending on configuration.
(In reply to Magnus Melin [:mkmelin] from comment #50) > What properties is it that cause a problem? I'm assuming they just have a wrong string type. Don't know which "properties" cause the problem and don't really even know what you mean by "property". I can tell that the problem occurs at two places where JS_EncodeStringToBuffer() is called here https://searchfox.org/comm-central/source/mozilla/js/xpconnect/src/XPCConvert.cpp#605 and here https://searchfox.org/comm-central/source/mozilla/js/xpconnect/src/XPCConvert.cpp#727 Edit: Permalinks not working currently for some reason. Replaced "rev/<long number>" with "source" now works. No idea why? The first call at line 604 is for string types: case nsXPTType::T_CHAR_STR: case nsXPTType::T_PSTRING_SIZE_IS: The other call at line 726 is for string type: case nsXPTType::T_CSTRING: In both cases the problem occurs when a UTF16 string is converted to a byte (UTF8) string and the upper byte is discarded. My fix is to keep the upper byte by decoding it in a different way (only if new parameter "losses" is true). Apparently with mozilla losses are never expected. With TB losses now only occur because folder names at this point are in UTF-16 and, with UTF8=ACCEPT active both byte are significant. With just mUTF7, the upper byte is always zero so no problem occurs. The actual discard/loss of the upper byte occurs here when decoding 2-byte char strings:https://searchfox.org/comm-central/source/mozilla/js/src/jsapi.cpp#4532 I really have no idea what controls this. But I see this code occur in conjunction with a when a message in a UTF8 encoded folder name with non-latin1 chars (>U+00FF) is accessed and it has attachments inline. It occurs after the full message is fetched and after the inline parts are accessed from offline store or ram cache depending on configuration. This also occurs when the compose window appears in response to a reply, forward, edit-as-new or edit draft when the recipient addresses are written to the fields. This is described in bug 1563891 comment 23.
(In reply to Magnus Melin [:mkmelin] from comment #50) > What properties is it that cause a problem? I'm assuming they just have a wrong string type. Don't know which "properties" cause the problem and don't really even know what you mean by "property". I can tell that the problem occurs at two places where JS_EncodeStringToBuffer() is called here https://searchfox.org/comm-central/source/mozilla/js/xpconnect/src/XPCConvert.cpp#605 and here https://searchfox.org/comm-central/source/mozilla/js/xpconnect/src/XPCConvert.cpp#727 Edit: Permalinks not working currently for some reason. Replaced "rev/<long number>" with "source" now works. No idea why? The first call at line 604 is for string types: case nsXPTType::T_CHAR_STR: case nsXPTType::T_PSTRING_SIZE_IS: The other call at line 726 is for string type: case nsXPTType::T_CSTRING: In both cases the problem occurs when a UTF16 string is converted to a byte (UTF8) string and the upper byte is discarded. My fix is to keep the upper byte by decoding it in a different way (only if new parameter "losses" is true). Apparently with mozilla losses are never expected. With TB losses now only occur because folder names at this point are in UTF-16 and, with UTF8=ACCEPT active both byte are significant. With just mUTF7, the upper byte is always zero so no problem occurs. The actual discard/loss of the upper byte occurs here when decoding 2-byte char strings:https://searchfox.org/comm-central/source/mozilla/js/src/jsapi.cpp#4532 I really have no idea what controls this. But I see this code occur in conjunction with a when a message in a UTF8 encoded folder name with non-latin1 chars (>U+00FF) is accessed and it has attachments inline. It occurs after the full message is fetched and after the inline parts are accessed from offline store or ram cache depending on configuration. Another different problem also occurs when the compose window appears in response to a reply, forward, edit-as-new or edit draft when the recipient addresses are written to the fields. This is described in bug 1563891 comment 23.