Bug 24855 - Font size cannot be "Normal" when user "Courier New" in Gmail
Summary: Font size cannot be "Normal" when user "Courier New" in Gmail
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows XP
: P2 Normal
Assignee: Nobody
URL: http://mail.google.com/
Keywords: GoogleBug, NeedsReduction
Depends on: 19161
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-26 13:59 PDT by xlyuan
Modified: 2010-09-27 18:39 PDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description xlyuan 2009-03-26 13:59:42 PDT
Build: Safari 4 Public Beta (528.16)
   OS: Windows, not test on Mac

Other Browsers:
Firefox3.0.7: OK
         IE8: OK
Chrome trunk: Fail

Steps:
1. Launch Safari
2. Sign in Gmail
3. Compose a new email
4. Type any text
5. Select the text
6. Try to change the font to "Courier New"
7. Observe

Result:
1. The font size for the text automatically changed to small after select font "Courier New"
2. Now, try to specify the font size as "Normal", nothing changed.

Expected:
Should be able to set font size "Normal" when use "Courier New" in Gmail

Notes:
1. This is also tracked in Chromium as crbug.com/7447
2. This might be related to https://bugs.webkit.org/show_bug.cgi?id=19643
Comment 1 Darin Fisher (:fishd, Google) 2009-03-26 14:01:29 PDT
It would help to have a regression window for WebKit nightly builds.
Comment 2 Eric Seidel (no email) 2009-03-26 14:03:02 PDT
This may be https://bugs.webkit.org/show_bug.cgi?id=21033.  Do we know what the gmail/trogedit code is doing here to determine "normal"?
Comment 3 Julie Parent 2009-03-26 14:32:50 PDT
The current size is fetched via queryCommandValue for fontSize.  The mapping from size to value is: 1: small, 2: normal, 4: large, 6: huge
Comment 4 Eric Seidel (no email) 2009-03-26 15:35:36 PDT
(In reply to comment #3)
> The current size is fetched via queryCommandValue for fontSize.  The mapping
> from size to value is: 1: small, 2: normal, 4: large, 6: huge

Except you must have some quirk for WebKit since https://bugs.webkit.org/show_bug.cgi?id=21033 documents that queryCommandValue("FontSize") returns pixel values in WebKit instead of <font size="n"> values like it does in IE.
Comment 5 Julie Parent 2009-03-26 16:04:34 PDT
Ah, yes, found this in Gmail code -
 switch (item) {
  781:           case '10px':
  782:             item = '1';
  783:             break;
  784:           case '13px':
  785:             item = '2';
  786:             break;
  787:           case '18px':
  788:             item = '4';
  789:             break;
  790:           case '32px':
  791:             item = '6';
  792:             break;
  793:           default: // Unexpected case - don't update the menu
  794:             return;
Comment 6 Jon@Chromium 2009-03-30 14:38:26 PDT
This appears to be a duplicate of 21033.

*** This bug has been marked as a duplicate of 21033 ***
Comment 7 Julie Parent 2009-07-20 14:07:01 PDT
I do not think these 2 bugs are dupes.  One existed long before the other.
Comment 8 Eric Seidel (no email) 2009-07-20 14:13:00 PDT
We need a reduction.

This might just be another dupe of https://bugs.webkit.org/show_bug.cgi?id=19161.  I don't see any mention that this is a regression from earlier versions of Safari.

Clearly TrogEdit has code to work around bug 21033.  Also clearly that code is failing in the "Courier New" case.  Whether it's a WebKit bug or a TrogEdit bug is not yet known.
Comment 10 Eric Seidel (no email) 2009-07-28 12:24:33 PDT
It seems Gmail could at least update their code to log in the case of an unexpected font-size. :)  That would have made this bug appear on their radar sooner, no? ;)
Comment 11 Eric Seidel (no email) 2009-07-28 13:09:57 PDT
It looks like TrogEdit/Gmail would not have this trouble if they used getComputedStyle instead of queryCommandValue in the WebKit case.  It seems our monospace quirk only exists in queryCommandValue... at least according to the test case on bug 21033
Comment 12 Ojan Vafai 2009-07-28 13:25:09 PDT
Getting the size numbers right doesn't fix bug 24855, it only makes the font-menu correctly identify the font-size as "normal". The bigger issue in bug 24855 is that the font-size shrinks when you change the font-family to Courier New.

There's no good workaround for gmail. They could take the "monospace" out of the font string, but then linux machines (which lack both courier and courier new by default I'm told) would get the fallback non-monospace font.

Fixing bug 19161 would also fix this.
Comment 13 Eric Seidel (no email) 2009-07-28 13:43:57 PDT
They could also vend different CSS to linux machines. :)  But yes, it's also possible to fix 19161.
Comment 14 Ojan Vafai 2009-07-28 14:17:10 PDT
Gmail does not control the platform the email is being read on.
Comment 15 Ryosuke Niwa 2010-09-15 20:48:37 PDT
Since the bug 19161 has been fixed, can we close this bug now?  I cannot reproduce the problem on gmail anymore.
Comment 16 Ryosuke Niwa 2010-09-27 18:39:50 PDT
Closing this bug since this bug seems to have been fixed and the problem no longer reproduces on TOT.