Submitted a pull request to wpt with a few reftests checking for this problem and variations of it:

https://github.com/w3c/web-platform-tests/pull/4608

@frivoal now that I'm taking a look into this, I'm wondering what should happen
with form elements like <input> when they're disabled.

Note that the behavior in Chrome is not consistent:
* For "contenteditable" elements and <textarea> when you move the focus out of them,
  the spelling markers are kept.
* For "input" when you move the focus out the spelling markers disappear.
  But if you sue "blur()" from JavaScript, the makers are kept.

In the attached example you can see the issues with the markers in disabled form elements.

Deleted: spelling-markers-2.html 1.2 KB

spelling-markers-2.html 1.2 KB View Download

Deleted: spelling-markers-2-current.png 15.1 KB

	spelling-markers-2-current.png 15.1 KB View Download

 Issue 155781  has been merged into this issue.

Re #2: The behavior that markers in <input> are removed on blur is intentional. I forgot the exact reason, which should be something like we don't want to have the page full of red underlines after filling a form.

#4 - so that should happen even by JavaScript-generated blurs, right?

@rego
Removing or not the markers on blur() is left up to the UA by the specification[1]:

> Even when checking is enabled, user agents may opt to not report spelling or grammar errors in text that the user agent deems the user has no interest in having checked (e.g. text that was already present when the page was loaded, or that the user did not type, or text in controls that the user has not focused, or in parts of e-mail addresses that the user agent is not confident were misspelt).

As for what should happen to the markers when the form control is disabled, that's also in the spec[1]:

> User agents must only consider the following pieces of text as checkable for the purposes of this feature:
> *  The value of input elements whose type attributes are in the Text, Search, URL, or E-mail states and that are mutable (i.e. that do not have the readonly attribute specified and that are not disabled).
> *  The value of textarea elements that do not have a readonly attribute and that are not disabled.
> ...

This part is captured in the tests I submitted to https://github.com/w3c/web-platform-tests/pull/4608

[1] https://html.spec.whatwg.org/multipage/interaction.html#spelling-and-grammar-checking

@xiaochengh: Yeah the thing for inputs seems intentional.
There's a comment in a different bug [1]:
"It prevents address forms (mostly INPUT) from being entirely red
for unrecognized cities, street names, people names, etc."

@xiaochengh, @phistuck: I've just realized that the JavaScript issue
is already reported in  bug #524426 .

@frivoal: Thanks for the clarifications from the specs point of view.
I guess the "disabled" form elements can be managed in a separated bug/patch.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=524426#c4

@rego: Sure. Whether you handle this as one patch of a few is not something I have an opinion on. I just dug into the spec to make sure we had the right behavior and wrote tests accordingly.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/03bd67fe0ded2c7031eb1c3efb39150056737492

commit 03bd67fe0ded2c7031eb1c3efb39150056737492
Author: rego <rego@igalia.com>
Date: Thu Feb 02 08:40:23 2017

Remove spelling markers when element is not editable

If you mark a contenteditable element as not editable,
any spelling marker that appears there should disappear.

This behavior was discussed and agreed with the CSS WG at:
https://github.com/w3c/csswg-drafts/issues/623

BUG=683896
TEST=editing/spelling/spellcheck-remove-markers.html

Review-Url: https://codereview.chromium.org/2650183002
Cr-Commit-Position: refs/heads/master@{#447727}

[add] https://crrev.com/03bd67fe0ded2c7031eb1c3efb39150056737492/third_party/WebKit/LayoutTests/editing/spelling/spellcheck-remove-markers.html
[modify] https://crrev.com/03bd67fe0ded2c7031eb1c3efb39150056737492/third_party/WebKit/Source/core/editing/spellcheck/SpellChecker.cpp
[modify] https://crrev.com/03bd67fe0ded2c7031eb1c3efb39150056737492/third_party/WebKit/Source/core/editing/spellcheck/SpellChecker.h
[modify] https://crrev.com/03bd67fe0ded2c7031eb1c3efb39150056737492/third_party/WebKit/Source/core/html/HTMLElement.cpp

The part related to "disabled" and "readonly" form elements
has been moved to bug #687949.

It's still pending to fix the issue if you set 'spellcheck="false"',
as right now the markers are not removed in that case.

Jubilation! This seems fixed for me, at least at v58.0.3029.110 on Windows 10. 

http://jsfiddle.net/RegVn/1/

I wonder if it's also fixed on Mac... 

(I come here from  Issue 155781 , care of https://stackoverflow.com/q/12812348)

I'm not currently working on this.

Anyway I'm leaving this open because of what's explained in comment #10:
> It's still pending to fix the issue if you set 'spellcheck="false"',
> as right now the markers are not removed in that case.