none
OWA - Message Mangling in Chrome

    Question

  • Hi All

    A bit of a strange one that's only cropped up since installing SP1

    If I compose an email in OWA in Chrome and use tab to move from the subject line to the main text, when the recipient receives the email there is a"?" before the main text - the recipient can be using a mail client or a browser to view the email.

    I have seen the "?" appearing in the Windows 8.1 Mail client and GMail so far (but the same email will not show the "?" in OWA).

    All I can guess is that somehow the tab character is getting inserted.  Chrome is up-to-date and it doesn't occur when the message is composed in IE or Firefox.

    Has anyone else experienced this?

    Cheers

    Andy


    Thursday, March 6, 2014 11:32 PM

Answers

  • OK, in case it helps anyone, I found an answer!

    It appears that all outgoing email was being converted to plain text resulting in the encoded character.

    "get-remotedomain | select contenttype" reported a type of MimeText, so I ran:

    "get-remotedomain | set-remotedomain -ContentType "MimeHTMLText" and now the encoding issues are gone with the added bonus of all emails now being in html format.

    Cheers

    Andy


    • Marked as answer by Ocky72 Friday, June 13, 2014 11:36 AM
    Friday, June 13, 2014 11:36 AM

All replies

  • OK, a little more detail investigation having tested on a number of machines.

    The character is actually a zero width space "&#8203"

    It does not display in Outlook or OWA but is definitely there.  In other mail clients it shows as a "?"


    Friday, March 7, 2014 11:13 AM
  • Hi Andy,

    Since the issue doesn’t occur when the message is composed in OWA with IE and it can be received correctly in OWA and Outlook, I think the issue should not be related to Exchange server.

    I also have tested in my Windows 8.1 with Outlook 2013, IE 11, Exchange 2010 SP3 environment, using Tab to move from the subject line to the main text in OWA didn’t cause any problem when receiving it in OWA and Outlook.

    If the issue only happens in Chrome, please update your web browser to the latest version to have a try or we can contact Chrome support for more help.

    Best Regards,


    Winnie Liang
    TechNet Community Support

    Tuesday, March 11, 2014 6:32 AM
    Moderator
  • Hi Winnie

    Thanks for your response

    I almost agree, but this behaviour started following the install of Exchange 2013 SP1 so it suggests to me that something changed in sp1.

    All versions tested are the latest version of Chrome (33.0.1750.146)

    Additionally I have rolled back to  32.0.1700.107 to rule out a Chrome update and found that the issue now exists there - prior to SP1 the issue did not exist.

    I have also logged this under Issue 350352 as a bug in Chrome (https://code.google.com/p/chromium/issues/detail?id=350352) but would not be surprised to be told it's application specific if lucky enough to get an answer.

    The issue occurs in Windows 7 (x64), Windows 8 (x64) and Windows 8.1 (x64).

    The character actually does exist in emails received in OWA and Outlook, but they both somehow choose to ignore it. 

    Cheers


    Andy


    Tuesday, March 11, 2014 9:55 AM
  • Hi all

    I've already posted about issues in Chrome, but thought I'd start a new question as it seems problems exist in firefox too, under similar circumstances.

    If you start a new message in Firefox (27.01) and pop the window out, then use the tab key to move between subject line and message body, when you hit return after the first line of your text the cursor appears to return to the start of the same line.

    On Chrome 33.0.1750.146 (as per my last post). If you start a new message inline or popped out and use tab to move from the subject line to the message body it results in a zero width space character ("​") in the email.  This does not display in Outlook or OWA but is there (you can see it if you view the message source in Outlook).

    Other clients such as the Windows 8 mail client, Outlook.com or Gmail show the character as a question mark (even when viewed in IE for the web based clients).

    It seems at present that only IE behaves itself properly when composing emails.

    Has anyone experienced these bugs or suggest a way forward.

    Thanks

    Andy

    • Merged by cara chen Thursday, March 20, 2014 1:02 AM repeated
    Friday, March 14, 2014 4:59 PM
  • Hi Andy,

    Since the issue does not occur in IE and Firefox, I think this is a compatibility with Chrome browser. According to this situation, I think it will be more efficient to discuss with Chrome support and see whether there are any hotfix for this issue.

    Thanks,


    Simon Wu
    TechNet Community Support


    Tuesday, March 18, 2014 3:11 AM
    Moderator
  • Hi Simon

    Thanks for the reply

    I have already logged this under issue 350352 at Chromium.

    However, I would guess (if it gets any attention) it may be suggested it is application specific and get bounced back as an OWA issue.

    I have also posted another question about Firefox issues following SP1, it seems that SP1 caused issues in both Chrome and Firefox - both related to tabbing out of the subject line.

    My guess is that both are getting this extra character but dealing with it in a different way, both causing issues.

    So, even if behaviour is presenting itself differently in both cases, there seems to be an issue with tabbing from the subject line to the message box in the major browsers excluding IE following Exchange 2013 SP1. 

    Cheers

    Andy

    Tuesday, March 18, 2014 9:07 AM
  • Helo Andy,

    After testing in my lab, I find when sending mail to internal user, it displays correctly both in Chorom and IE. Is it the same on your side?

    Meanwhile, Could you send the mail using plain text format in OWA and see if the result is the same?

    Asides, after checking the HTML Entity, it doesn't show "&#8203". It can be that this is unrecognized html entity.

    http://www.w3schools.com/charsets/ref_html_entities_4.asp

    For our issue, it can be that if this entity is unrecognized, IE will ignore this, but other browsers will not.

    If anything unclear of above information, feel free to contact us.

    Sent By

    Silver Shen

    Thursday, March 20, 2014 7:52 AM
    Moderator
  • Hi Silver Shen

    Thanks for the response

    Yes, it displays correctly if viewed in OWA in any browser.  However, if you view the source you can see the character is still there (the same in Outlook).

    If sent in plain text the character is not there.

    If I compose an email using Chrome in OWA using tab to switch between fields, sending it to an external address such as one @outlook.com (or gmail, etc), when the received email is viewed the extra character is visible no matter what browser it is viewed with (including IE)

    Cheers

    Andy

    Thursday, March 20, 2014 12:24 PM
  • Helo Andy,

    Thanks for your reply. From your description, I know our issue is only wth HTML format. Meanwhile, as you mentioned, when viewed the message in OWA in any browser, it displays correct.  But when send mail to external email address in Chrome, the "?" appears.

    After doing some more research, I find  this character is intended for line break control; it has no width, but its presence between two characters does not prevent increased letter spacing in justification. See more details in the following link: http://stackoverflow.com/questions/2973698/whats-html-character-code-8203

    As it only appears in exchange 2013 SP1. it seems the HTML character is recorded in this new version. And this seems the change between exchange 2013 CU3 and exchange 2013 SP1.And it seems exchange can recognize this character and ignore this automatically. But other mail server (gmail server) will not. It can be the compacility issue with exchange 2013 SP1, Chrome and Outside mail server.

    Best regards!

    Silver Shen

    Friday, March 21, 2014 8:31 AM
    Moderator
  • Hi again Silver Shen

    Glad you managed to confirm the issue, thought it was only me!

    Any suggestions how I could raise the profile of the issue to see if we can get it fixed? 

    If it was just an issue with gmail I'd be less worried but as it seems to affect all non-OWA systems it's a little more concerning.

    Cheers

    Andy

    Friday, March 21, 2014 10:45 AM
  • Helo Andy,

    It seems this is a compacility issue. Given the situation, we recommend to change the habit to new/edit a mail firat firat. Meanwhile, we will forward your finding to our related team. But we need some more details information. Could you get a screen shot of the character information, the location you view in the source and how you find this?

    Thanks!

    Sent By

    Silver

    Saturday, March 22, 2014 1:58 AM
    Moderator
  • Hi Silver

    Here's a screenshot of the issue showing in the source of an email in Outlook (the easiest place to find it)

    Although Outlook does not show it the character is still there and displays on non-Outlook/OWA clients.

    If you view source in any other client (eg Outlook.com) you can see the issue.  I'm happy to provide any more information that may be required.

    Cheers

    Andy

    Monday, March 24, 2014 10:31 AM
  • Helo Andy,

    Thanks for your reply. From the picture you provided, I know the code is seen in the outlook when we click view source. After doing test on exchange 2013 former version and exchange 2013 SP1. Here is my finding:

    On exchange 2013 SP1.

    • When send mail via Chrome, the code is existing the information is as below:

    • When send mail via IE, the code is not existing, the information is as below:

    It seems Chrome browser has generated $#8203 and<br>automatically. While IE hasn't.

    As the issue is existing after we upgrade to exchange 2013 SP1. Then I do a test on exchange 2013 former version as well. And find something change. The change is that in exchange 2013 SP1, the content will be added in "<p> </p>" Under "<div> </div>. But in former version, the content is under "<div> </div>" directly.

    ======================================

    <div name="divtagdefaultwrapper" id="divtagdefaultwrapper" style="font-family: Calibri,Arial,Helvetica,sans-serif;font-size: 12pt;color: #000000;margin: 0;">test</div></body></html>

    ======================================

    From above phenomenon, it seems our issur is related to Chrome browser. Could you contact them to see if they can look into above information?

    Sent By

    Silver Shen

    • Marked as answer by Ocky72 Tuesday, March 25, 2014 10:00 AM
    • Unmarked as answer by Ocky72 Friday, June 13, 2014 11:36 AM
    Tuesday, March 25, 2014 9:00 AM
    Moderator
  • Hi Silver

    Thanks for your work on this.

    I have added your info to the issue I opened on Chromium (350352), but so far this has not attracted any attention.  From previous experience it can take a long time before anything is picked up.

    Cheers

    Andy

    Tuesday, March 25, 2014 9:36 AM
  • Hi Andy,

    Thanks for your reply. If there's any update from their side or you need our help in the future, we can continue contacting us. We will try our best to help you.

    Thanks!

    Sent By

    Silver Shen

    Tuesday, March 25, 2014 9:50 AM
    Moderator
  • Excellent - thanks Silver, much appreciated.

    Andy

    Tuesday, March 25, 2014 10:01 AM
  • OK, in case it helps anyone, I found an answer!

    It appears that all outgoing email was being converted to plain text resulting in the encoded character.

    "get-remotedomain | select contenttype" reported a type of MimeText, so I ran:

    "get-remotedomain | set-remotedomain -ContentType "MimeHTMLText" and now the encoding issues are gone with the added bonus of all emails now being in html format.

    Cheers

    Andy


    • Marked as answer by Ocky72 Friday, June 13, 2014 11:36 AM
    Friday, June 13, 2014 11:36 AM
  • Where did you run "get-remotedomain | set-remotedomain -ContentType "MimeHTMLText"?
    Wednesday, February 4, 2015 2:40 PM
  • Open the Exchange Management Shell as admin and run it there. 

    The Exchange role of the server shouldn't be important as far as I know but we have dual role CAS/Mailbox servers.

    Wednesday, February 4, 2015 4:28 PM
  • I'm having this exact same issue. Exact same symptoms in the same situation. However, my Exchange server is already set to MimeHtmlText. Any ideas?
    Wednesday, November 18, 2015 10:00 PM
  • Same issue here.  It's really messing up our Zendesk tickets having all these extra '?' show up everywhere.  We run in in house Exchange 2013 CU10  server.  Using latest Chrome v47.0.2526.111 (64-bit) at this time. We are also already set to MimeHtmlText.

    Anyone found a working solution??

    UPDATE: I noticed that the old issue that Andy opened almost 2 years ago was closed for inactivity. What a shame!  I filed a new bug at Chromium #578155

    Everyone please go STAR and COMMENT on that to give it some attention if you want to see this fixed. Thanks


    Thursday, January 14, 2016 5:46 PM
  • Hi Andy,

    Since the issue does not occur in IE and Firefox, I think this is a compatibility with Chrome browser. According to this situation, I think it will be more efficient to discuss with Chrome support and see whether there are any hotfix for this issue.

    Thanks,


    Simon Wu
    TechNet Community Support


    Simon

    I have filed a bug at Chromium #578155 but so far it is ignored.

    Is it possible for a fix to be implemented by Microsoft themselves? I inspected the server side javascript and found that the Zero White Space (ZWSP) character is definitely inserted by the file microsoft.exchange.clients.owa2.client.core.controls.richtexteditor.js near OWAZWSPSpan itself. See screenshot below.  Looks like sort of a placeholder for the span when it's empty maybe before the user starts typing in the body.  I can't really read the code but it seems like a fix might be possible from Microsoft's end by using a &nbsp instead or something similar.

    • Proposed as answer by Speckk Friday, July 1, 2016 5:21 PM
    Saturday, January 23, 2016 5:33 PM
  • This totally worked for me!  Thanks!  Tested it by changing back and forth.   I found that if you replied with anything other than IE (like Chrome, Safari, etc) then it would add a ? at the beginning of the first sentence.  Maddening!
    Tuesday, May 24, 2016 4:53 PM
  • It looks like Lighthouse has pinpointed this problem in Exchange's JavaScript.

    I had to google "OWA adding extra characters and breaking email commands" to find this thread.

    I kept issuing email commands to my listserv server from OWA, and getting this error back like:

    "> ?HELP

    Unknown command - "?HELP". Try HELP.

    "

    What will it take for the Exchange team to fix this Javascript bug?

    Friday, July 1, 2016 5:21 PM