Bug 153290 – [GTK] Red sqiuggly line under misspelled word disappears when cursor is on word

• Component: WebKitGTK
• Status: NEW

[Michael Catanzaro]

I will use the ^ to indicate the character that the cursor is positioned immediately IN FRONT OF. Type this in a text field:

sqigggly 
         ^

Note the one space after the word, needed to trigger the spellchecker to consider it a misspelled word.

Now press the left arrow key once, so you get this:

sqigggly 
        ^

The red squiggly line goes away. It also goes away if you right click on it to show the context menu. I dunno if this is how spellcheckers work on Mac, but that's not expected behavior on Linux.

[Joanmarie Diggs]

This issue has some interesting implications for screen reader users who navigate into the text. Orca uses the accessible text attributes to identify the presence of the red squiggly and speak "misspelled" when that attribute is present.

(Note: At the moment there are some other, accessibility-related bugs which are interfering with the aforementioned functionality. But when those are addressed, it would be nice if arrowing into the error didn't make the error indication vanish. So that Orca could make this presentation.)

[Adrien Plazas]

Created attachment 270985 [details]
Don't erase spelling markers after selection change on GTK+.

[Xabier Rodríguez Calvar]

Comment on attachment 270985 [details]
Don't erase spelling markers after selection change on GTK+.

View in context: https://bugs.webkit.org/attachment.cgi?id=270985&action=review

> Source/WebKit2/ChangeLog:8
> +        Reviewed by NOBODY (OOPS!).
> +
> +        * WebProcess/WebCoreSupport/WebEditorClient.cpp:

You could either write an explanation between this two lines or in the function section, but you'd need at least something

[Adrien Plazas]

Created attachment 270988 [details]
Don't erase spelling markers after selection change on GTK+.

[Michael Catanzaro]

Comment on attachment 270988 [details]
Don't erase spelling markers after selection change on GTK+.

Well, I agree with the change in this patch, to return type != TextCheckingTypeSpelling here like the other ports do. It seems to do the right thing, fixing both of my complaints: the squiggly line disappearing when you right click to get a context menu, and the squiggly line disappearing when you move the cursor back one position.

But it breaks spellchecking of contractions, e.g. "wasn't." Strange, Mac port must be handling contractions differently somewhere else.

[Michael Gratton]

This sounds a lit like Bug 153290. Is there some overlap?

[Michael Gratton]

Err, I mean Bug 32770. Apologies!

[Michael Catanzaro]

(In reply to Michael Gratton from comment #6)
> This sounds a lit like Bug 153290. Is there some overlap?

I think bug #32770 is completely different. That bug complains that spelling suggests do not appear when right-clicking on the word unless the word is selected. That's definitely not the case today, so I'll close that bug as obsolete.