Red spellcheck squiggles remain in chrome after editing is disabled

Question

UPDATE: This has been identified as a bug in Chrome. (Thanks @michael-robinson)

In Chrome (v22 at least), I notice that it's possible for spellchecking "red squiggly" underlines to remain even after contentEditable has been disabled.

I made a jsfiddle to demonstrate: jsfiddle demo.

squiggles and spelling errors

Even if I set the attribute spellcheck="false" before disabling contentEditable, they remain.

Anyone know how a nice way to solve or work around this? Ideally I'd retain the built-in spell checking functionality when the content is editable.

What about instead of disabling the contentEditable, you remove the attribute? — Brian Noah, Oct 10 '12 at 05:15
@BrianNoah I'll give it a go, although the contentEditable attribute seems to be respected with a value of `false` — aaaidan, Oct 10 '12 at 05:19
@BrianNoah Nah, doesn't seem to change the broken behaviour of the spellcheck underlines. Thanks, though. — aaaidan, Oct 10 '12 at 05:24
Thought I'd try, Have you tried the autocorrect="false" attribute? — Brian Noah, Oct 10 '12 at 05:25
This is a bug in chrome and has been reported here: [Issue 155781](https://code.google.com/p/chromium/issues/detail?id=155781&q=spellcheck&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20Modified) — Michael Robinson, Mar 27 '13 at 20:20
Awesome, I actually submitted that, but hadn't realised they'd picked it up... — aaaidan, Mar 29 '13 at 00:53

score 3 · Accepted Answer · edited Oct 25 '14 at 17:41

3

~~Have you tried setting display: none (using CSS) and then setting the display back to what it was? Might force Chrome to redraw the element...~~ (didn't work, see other solution below)

Alternatively, you could create a copy of the element (but with contenteditable disabled) placing it just after the original element and deleting the original element.

UPDATE 1: first solution didn't work, but second one does. Updated JSfiddle http://jsfiddle.net/RegVn/6/

UPDATE 2: above solution uses innerHTML which removes destroys event handlers. It also destroys the selection/caret position.

New method uses jQuery's clone() method (in deep clone mode) to create a copy of the object (which copies over the event handlers), and has custom functions to save a reference to the selection, and restore it afterwards. Note that the selection save/restore functions wont work in ie6-8, but I thought that this was acceptable as the question is tagged Chrome. Updated JSfiddle: http://jsfiddle.net/RegVn/23/

edited Oct 25 '14 at 17:41

BAR

15,909
27
97
185

answered Oct 11 '12 at 12:19

Nico Burns

16,639
10
40
54

Creating a new element which is the same as the old one works - I've updated the JSfiddle with an example (see edited answer). – Nico Burns Oct 15 '12 at 00:14
Hey, thanks heaps for creating a jsfiddle to demonstrate, I appreciate that. Unfortunately this solution has a few significant drawbacks which I outline in my answer below: http://stackoverflow.com/a/12888119/26331 – aaaidan Oct 15 '12 at 01:30
1

@aaaidan Updated to remove 2 of your drawbacks. I'm afraid this is probably still quite cpu intensive (if not more so), but it does address the other problems. – Nico Burns Oct 15 '12 at 14:54
1

Brilliant! This is an excellent workaround. I had no idea that a deep clone preserved events, thanks! I commented the line forcing contentEditable on removing the squiggs, and removed lines when leaving edit mode: http://jsfiddle.net/RegVn/26/ – aaaidan Oct 15 '12 at 22:33

score 3 · Answer 2 · answered Jun 22 '17 at 18:57

3

Adding the attribute spellcheck="false" to the element works for me.

answered Jun 22 '17 at 18:57

besrabasant

2,422
6
27
41

1

Haha, jubilation! This must be fixed now. I'll check. Cheers – aaaidan Jun 22 '17 at 20:31

score 1 · Answer 3 · answered Oct 10 '12 at 16:01

1

The spellcheck attribute specifies whether the element is to have its spelling and grammar checked or not:

spellcheck="false"

answered Oct 10 '12 at 16:01

Eric MSFT

3,246
1
18
28

Ah, thanks - I should probably mention that they persist even if spellcheck="false" is set after they appear. – aaaidan Oct 11 '12 at 00:04

score 1 · Answer 4 · answered Oct 15 '12 at 01:13

If you update the innerHTML of the element, the spellcheck will be re-evaluated, so they'll disappear if spellcheck="false" or if the element isn't editable.

For example:

myElement.innerHTML = myElement.innerHTML + " "; // add a space to force a change.

This has significant disadvantages:

Event handlers and javascript objects referencing any elements will be invalidated (all elements inside the element are effectively removed from the dom). This also means that javascript-only properties, such as a checkbox's indeterminate property or any other custom properties, will be destroyed.
The selection or caret position is destroyed.
If you have a large amount of content, this is a non-trivial operation for the cpu, especially on mobile.

This is okay for now, but I'm still looking for a better answer. Suggestions?

See above again. I can't make it less cpu intensive (it is possible that there is another approach which would allow this), but the new method will keep event handlers and restore the selection. — Nico Burns, Oct 15 '12 at 17:47

score 0 · Answer 5 · answered Nov 04 '13 at 00:15

0

var content = $("#editor").html();
$("#editor").html("")
$("#editor").attr('spellcheck', 'false');
$("#editor").html(content);

try this code and it should work. This is based on the same previous answer of cloning inner HTML.

Works in FF and Chrome.

answered Nov 04 '13 at 00:15

Sarvesh

1,152
2
11
25

Great, this is compact and easy to understand. But unfortunately, it will will destroy any event handlers that exist for the content. – aaaidan Nov 19 '13 at 04:26

Red spellcheck squiggles remain in chrome after editing is disabled

5 Answers5