Bug 24855
| Summary: | Font size cannot be "Normal" when user "Courier New" in Gmail | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | xlyuan |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | Normal | CC: | arv, eric, jon, jparent, jshin, ojan, rniwa |
| Priority: | P2 | Keywords: | GoogleBug, NeedsReduction |
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| URL: | http://mail.google.com/ | ||
| Bug Depends on: | 19161 | ||
| Bug Blocks: | |||
xlyuan
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
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Darin Fisher (:fishd, Google)
It would help to have a regression window for WebKit nightly builds.
Eric Seidel (no email)
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"?
Julie Parent
The current size is fetched via queryCommandValue for fontSize. The mapping from size to value is: 1: small, 2: normal, 4: large, 6: huge
Eric Seidel (no email)
(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.
Julie Parent
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;
Jon@Chromium
This appears to be a duplicate of 21033.
*** This bug has been marked as a duplicate of 21033 ***
Julie Parent
I do not think these 2 bugs are dupes. One existed long before the other.
Eric Seidel (no email)
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.
Eric Seidel (no email)
When I do a simple example in plexode, I don't notice anything that looks like a bug:
http://www.plexode.com/cgi-bin/eval3.py#ht=%3Cdiv%20id%3D%22foo%22%20contentEditable%20style%3D%22font-family%3A%20courier%20new%22%3Etest%3C%2Fdiv%3E&ohh=1&ohj=1&jt=getSelection().selectAllChildren(foo)%0Adocument.queryCommandValue('FontSize')&ojh=1&ojj=0&ms=100&oth=0&otj=0&cex=1
But when I use "courier new, monospace" instead of just "courier new", then I get 12px, which is presumably why gmail is failing.
http://www.plexode.com/cgi-bin/eval3.py#ht=%3Cdiv%20id%3D%22foo%22%20contentEditable%20style%3D%22font-family%3A%20courier%20new%2C%20monospace%22%3Etest%3C%2Fdiv%3E&ohh=1&ohj=0&jt=getSelection().selectAllChildren(foo)%0Adocument.queryCommandValue('FontSize')&ojh=1&ojj=0&ms=100&oth=0&otj=0&cex=1
gmail could fix this by not sending "monospace" to WebKit.
With that hypothesis, this becomes a dupe of:
https://bugs.webkit.org/show_bug.cgi?id=19161
Eric Seidel (no email)
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? ;)
Eric Seidel (no email)
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
Ojan Vafai
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.
Eric Seidel (no email)
They could also vend different CSS to linux machines. :) But yes, it's also possible to fix 19161.
Ojan Vafai
Gmail does not control the platform the email is being read on.
Ryosuke Niwa
Since the bug 19161 has been fixed, can we close this bug now? I cannot reproduce the problem on gmail anymore.
Ryosuke Niwa
Closing this bug since this bug seems to have been fixed and the problem no longer reproduces on TOT.