Bug 12812 – REGRESSION: In Gmail Check Spelling As you Type underline doesn't cover certain words

• Status: NEW
• Component: New Bugs

[Stephen Harbage]

Summery:
If you have Check Spelling as You Type on in Gmail certain wrongly spelt words don't have the red underline covering them properly.

Steps to reproduce:
1. Go to Gmail>compose
2. Ctrl/right-click and ensure Spelling>Check Spelling as you type is ticked
3. type in the Google search at the top, To: Subject: or the bit where you type in the actual message:
ruth
hellloi
needgod

This works fine in 419.3 but in the nightly the red underline doesn't cover the words properly.

Works fine in other sites with text boxes e.g.
http://www.apple.com/macosx/feedback/

Some words work fine but others don't for some reason

[Stephen Harbage]

Created attachment 13240 [details]
Ruth example 1

[Stephen Harbage]

Created attachment 13241 [details]
Ruth example 2

[Vladimir Olexa (vladinecko)]

Created attachment 13286 [details]
Text areas showing different text sizes

I'd like to point out that this is not a Gmail specific issue but rather it depends on font size. Also, different font-families make a little difference in how the underlining renders. 

The attached test case shows 2 textareas with two different font sizes. 13px Arial is what Gmail uses in their email body. 

Also, as you make text bigger/smaller in the browser, the underlining changes to proper length.

[Antti Koivisto]

A comment in GraphicsContext::drawLineForMisspellingOrBadGrammar() says

// Make sure to draw only complete dots.
// NOTE: Code here used to shift the underline to the left and increase the width
// to make sure everything gets underlined, but that results in drawing out of
// bounds (e.g. when at the edge of a view) and could make it appear that the
// space between adjacent misspelled words was underlined.

Apparently underlining was made shorter on purpose. Still, perhaps it should at least be centered to make it look better? Anyway, doesn't seem like a P1.

In the 11px example, WebKit matches AppKit and it is not a regression from Safari 2.0.4. In the 13px example, AppKit extends the line by one dot to the right (tested in Tiger). Seems like WebKit needs to use the same logic and draw more dots.

[Andrew Wellington]

While it is simple enough to make WebKit draw a longer line that matches AppKit, this reintroduces the problem solved in r8649 (rdar://problem/3943090) where the line isn't completely erased in some circumstances. To solve that problem the code that removes markers (misspelling is removed by removing a marker from the document) will need to repaint slightly more than just the node in question or it will leave fragments of the line in some cases.

[Maciej Stachowiak]

<rdar://problem/5028156>

[Darin Adler]

Despite the fact that this is a regression, it's costmetic and should not be marked P1.