905940 - [Buri][Email] E-mail app compose UI uses a non-monospace font but the message reader uses a monospace to display text/plain; the received message may display slightly differently for font reasons

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.184
 Firefox os  v1.1
 Mozilla build ID:20130806071254
 
 Created an attachment (id=466776)
 pic-issue
 
 DEFECT DESCRIPTION:
 
  The content display abnormally when you receive the mail.
  REPRODUCING PROCEDURES:
 
  1.Login in a gmail account 
  2.Receive a mail that the content contains"000000",read the mail ,you will find that the content display abnormally.--->KO
 
  EXPECTED BEHAVIOUR:
 
  The content should display"000000",display normally.
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
  mid
  REPRODUCING RATE:
  5/5
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Clone from brother

Comment 2

[sync-1]

Attachment: pic-issue

Comment 3

[sync-1]

Clone from brother

Comment 4

[sync-1]

Attachment: QXDM_log

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

We use a monospace font when we receive text/plain messages, but we're not using a monospace font during the compose process when we create text/plain messages.  The monospace font tries to clearly distinguish between the number 0 and the letter O.

The choice of a monospace font for text/plain display was made for consistency with Thunderbird's defaults.  Changing it is a UX call.  Needinfo'ing Rob since changes to message display are a koi/1.2 goal, althyough there is no spec yet, so it might slip to 1.3.

Comment 6

[Patryk Adamczyk [:patryk] UX]

Andrew, in 1.1 you should see a new font... Fira Mono, you can use that as the default for simple text email. Which should read nicer than what is the current default. I do think there is a benefit to show a difference between Simple text and HTML emails.

Comment 7

[Stephany Wilkes]

Removing the flag for Rob since Patryk addressed this. Thanks, Patryk!

Comment 8

[James Zhang (Spreadtrum)]

Attachment: email_display_error.patch

This bug is still on v1.3, please help to fix it.

Comment 9

[James Burke [:jrburke]]

In comment #6, a UX person, Patryk, indicated that there is benefit between showing a difference between simple text and HTML emails via a font choice, but his choice was for using the "Fira Mono" font.

Has there been an update from UX since then that suggested the change in the patch to use "font-family:arial,sans-serif;"?

Comment 10

[Jason Smith [:jsmith]]

Not a regression, so this is not a blocker.

Comment 11

[Evelyn Hung]

Comment on attachment 8359029 [details] [diff] [review]
email_display_error.patch

I'm not the one who can review email app's patch. redirect to :jrburke.

Comment 12

[James Burke [:jrburke]]

Comment on attachment 8359029 [details] [diff] [review]
email_display_error.patch

Review of attachment 8359029 [details] [diff] [review]:
-----------------------------------------------------------------

Removing review flag until we get UX confirmation of the change. Flagging Juwei, the current UX owner for email. I will flip it back to me to review if UX wants to proceed.

Juwei, see previous comments for background. Last UX guidance was not in line with the patch, but best to get a fresh perspective on it.

Comment 13

[Juwei Huang[:juwei]]

Re-flag to Patryk for visual confirm.
Hi Patryk, should we use "FiraSans" for reading message and "FiraMono" for compose UI ?

Comment 14

[Patryk Adamczyk [:patryk] UX]

The more I think about it and compare all other email clients (desktop and mobile), I would opt for the best user experience. That would be a font that is nice to read. The monospaced font has its advantages in spreadsheets and coding, plain text emails used a monospaced or generic font since that was the system "fall back" or default. I don't believe the average user, our users who are less tech centric care for that legacy design choice, they will probably ask... why on some emails the text looks one way and on others it looks another way.

Also I would suspect most email would be recieve in plain text.

So lets make plain text email use Fira Sans for both reading and composing.
As technology progresses there is less need to make that distinction.

Comment 15

[James Burke [:jrburke]]

Attachment: GitHub pull request

Changes text-only emails to use default non-monospace font, and matches its size with what is used for compose. Compose also removes the use of a monospace font.

Asking :asuth to review for historical context reasons. I will attach a screenshot of how it looks like now for a text email and compose.

Comment 16

[James Burke [:jrburke]]

Attachment: Capture of text email and compose with a non-monospace font

Capture of how it looks with the latest patch.

The screen on the left is a text only email using the inherited font, and the one on the right is compose using the inherited font, not a monospace one.

Asking Patryk for needsinfo to confirm it matches UX desires.

Comment 17

[Patryk Adamczyk [:patryk] UX]

Look(In reply to James Burke [:jrburke] from comment #16)

Looks correct to me. Thanks.

Comment 18

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8367675 [details] [review]
GitHub pull request

I'm pretty sure users actually want Comic Sans, but okay ;)

Comment 19

[James Burke [:jrburke]]

Merged in gaia master:
https://github.com/mozilla-b2g/gaia/commit/09064f43116d1b965cb3ab6516fa0f1fa3c98a4c

from pull request:
https://github.com/mozilla-b2g/gaia/pull/15821

Comment 21

[James Burke [:jrburke]]

Bug 988747 asked for 1.3? and the end result fix is the same as the fix in this ticket, so nomming this one instead and marked 988747 as a dupe.

Comment 22

[Jason Smith [:jsmith]]

(In reply to James Burke [:jrburke] from comment #21)
> Bug 988747 asked for 1.3? and the end result fix is the same as the fix in
> this ticket, so nomming this one instead and marked 988747 as a dupe.

If that's the case, then this isn't a regression. This bug has been present since 1.1 & was fixed for 1.4, so this wouldn't block.