White-space added to spell check mark

RESOLVED INACTIVE

Status

()

Core
Spelling checker
RESOLVED INACTIVE
7 years ago
3 days ago

People

(Reporter: gnothi.seauton, Unassigned)

Tracking

6 Branch
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Created attachment 559845 [details]
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.
(Reporter)

Updated

7 years ago
OS: Linux → All
Attachment #559845 - Attachment mime type: text/plain → text/html
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

7 years ago
Yes, this is the expected behavior.  In general, we never show the misspelling underline on words which are being edited.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
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

7 years ago
(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.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
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.
Severity: critical → normal
Summary: Spell checked words lose underlining when new line is deleted → White-space added to spell check mark

Comment 6

3 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago3 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.