686287 - White-space added to spell check mark

Status: REOPENED

(Core :: Spelling checker, defect)

Description

[gnothi.seauton]

Attachment: Two examples with reproduction steps

If you place the caret (cursor) in front of an underlined (i.e. misspelled) word, then press [Enter], then [Backspace], underlining is gone.

If you place the caret (cursor) in front of an underlined (i.e. misspelled) word at the beginning of a line, then press [Backspace] and the underlining is gone.

This happens very often when you delete blank lines in a textarea.

Bug seems to be triggered by deletion of a new line character.

See attachment for examples.

May be connected to Bug 520382.

Comment 1

[Jonathan Kew [:jfkthame]]

Does the spell-check underline reappear as soon as you move the cursor away from the incorrect word?

I think what's happening is that the backspace is seen as initiating an editing action that may involve the misspelled word (because it's modifying the text exactly at the word edge), and as long as that word is actively being edited, spell-checking isn't applied to it. As soon as you move the cursor away (e.g. with arrow keys, or click elsewhere), the editing of that word is finalized and it is again spell-checked.

Not sure if this should be considered a bug, or expected behavior. In general we don't want to mark "misspellings" of words while they're in the process of being typed/edited; this would be very distracting.

Comment 2

[(no longer active)]

Yes, this is the expected behavior.  In general, we never show the misspelling underline on words which are being edited.

Comment 3

[Jonathan Kew [:jfkthame]]

Right, that's what I assumed. However, I did wonder whether we should try to be "smarter" about what it means to be editing a word..... it'd be nice if just modifying the whitespace adjacent to a word (as in the examples here) did not actually cause the spell-check status of the word to change, as the actual range of the word itself is not being extended or modified at all.

Also, in experimenting with the testcase here, I noticed an inconsistency in behavior that I think does qualify as a bug, regardless of the above. Load the testcase, and place the cursor immediately before the last word ("erorr") in the first text area. Then, instead of pressing Enter (which will remove the underline), try typing an extra space (or several). What I see (in a Nightly build) is that the underlining remains, and the newly-entered space(s) get included in the "misspelled" range!

But then pressing Backspace to remove the newly-typed space _does_ remove the underline from the entire word. So I think the behavior w.r.t. whitespace changes adjacent to the word is not as straightforward or consistent as it ideally should be.

Comment 4

[(no longer active)]

(In reply to Jonathan Kew from comment #3)
> Right, that's what I assumed. However, I did wonder whether we should try to
> be "smarter" about what it means to be editing a word..... it'd be nice if
> just modifying the whitespace adjacent to a word (as in the examples here)
> did not actually cause the spell-check status of the word to change, as the
> actual range of the word itself is not being extended or modified at all.

Sure, I'm reopening this bug for that...

> Also, in experimenting with the testcase here, I noticed an inconsistency in
> behavior that I think does qualify as a bug, regardless of the above. Load
> the testcase, and place the cursor immediately before the last word
> ("erorr") in the first text area. Then, instead of pressing Enter (which
> will remove the underline), try typing an extra space (or several). What I
> see (in a Nightly build) is that the underlining remains, and the
> newly-entered space(s) get included in the "misspelled" range!

Yes, that's bad.  Please file another bug for it?

> But then pressing Backspace to remove the newly-typed space _does_ remove
> the underline from the entire word. So I think the behavior w.r.t.
> whitespace changes adjacent to the word is not as straightforward or
> consistent as it ideally should be.

Well, the code is really complex.  We don't handle whitespace around the insertion point correctly all the time, and sometimes this whitespace can fall into the "don't check" range, which causes the misspelling underlines to not be changed.

Comment 5

[Jorg K (CEST = GMT+2)]

I'm taking the liberty to lower the importance and change the summary. The bug I can reproduce in FF 43 is that in <textarea>hello errorr erorr</textarea> white-space is underlined if typed in front of the second error "erorr".

There are other aspects of the bug, like cancelling check marks when white-space adjacent to the misspelled word is modified, but that's less of an issue.