| 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: | |||
It would help to have a regression window for WebKit nightly builds. 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"? The current size is fetched via queryCommandValue for fontSize. The mapping from size to value is: 1: small, 2: normal, 4: large, 6: huge (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. 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;
This appears to be a duplicate of 21033. *** This bug has been marked as a duplicate of 21033 *** I do not think these 2 bugs are dupes. One existed long before the other. 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. 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 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? ;) 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 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. They could also vend different CSS to linux machines. :) But yes, it's also possible to fix 19161. Gmail does not control the platform the email is being read on. Since the bug 19161 has been fixed, can we close this bug now? I cannot reproduce the problem on gmail anymore. Closing this bug since this bug seems to have been fixed and the problem no longer reproduces on TOT. |
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