799475 - Spellcheck textareas without focus

Status: NEW

(Core :: Spelling checker, defect)

Description

[Chris Jaure]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4

Steps to reproduce:

Prior to version 10(?) Firefox would spellcheck all textareas on the page. We depended on this feature for our editorial system. Recently, we've upgraded to 15 and lost this feature (relevant ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=364914).


Actual results:

Textareas are now only spell checked when they are focused.


Expected results:

We would like a way to force spell check on init. It was mentioned in the ticket above that adding a "spellcheck=true" attribute to a textarea should spell check it upon init. That would be an acceptable solution for us.

Comment 1

[(no longer active)]

(In reply to Chris Jaure from comment #0)
> We would like a way to force spell check on init. It was mentioned in the
> ticket above that adding a "spellcheck=true" attribute to a textarea should
> spell check it upon init. That would be an acceptable solution for us.

I think that makes sense.  We should also force spell check when the attribute is set after the textarea being initialized.

Aryeh, can you please take this?  Thanks!

Comment 2

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

I'm a bit leery about spellcheck=true being overloaded to mean this.  It only works for textareas because they're spellchecked by default.  What if you want a single-line input to be spellchecked without being focused?  What if some browser doesn't spellcheck textareas by default, and authors set spellcheck=true so that it does?  The spellcheck attribute is meant to control whether textareas are spellchecked at all, not whether they're spellchecked as soon as the page loads vs. later.

Also, do we really need a declarative way to do this?  Why can't you just focus() and then blur() the textarea as soon as it loads?  You can save and restore the selection if you want to avoid disrupting the user experience too much.  This isn't ideal, but it could be a usable workaround.  It's what we do in our own reftests (where we don't care much about disrupting UX :) ).

If we do really need a dedicated way to do this, I suggest adding more values to the spellcheck attribute to control the behavior, or adding a spellcheck() method, or something like that.  I don't think overloading spellcheck=true is the right way to go.

Comment 3

[Chris Jaure]

Our editors have spellcheck enabled for multi-line controls and single-line controls (using layout.spellcheckDefault) so whatever solution is chosen should work for more than just textareas.

Right now, I am using a javascript solution to focus all the inputs and textareas, but that turns out to be more hacky than it seems: focusing fields does nothing when the page is loaded in a new tab in the background so the page visibility api needs to be utilized, triggering the focus events on fields could produce unintended side effects, consistent initial page scroll is hard to maintain, etc.

Since the spellcheck attribute is just for indicating whether a field should be spell checked and the spec makes no mention of *when* that should happen, perhaps a different solution would be desirable. It makes the most sense to me to add a new setting to about:config since there's already layout.spellcheckDefault that affects the behavior of the spellchecker.

Comment 4

[(no longer active)]

So as far as I can see, the HTML5 spec says nothing about when spell checking should happen.  Now, we don't spell check textareas until they're focused as an attempt to make the UX better for textareas that display text which is not really entered by the user.

How about just exempting textareas with spellcheck=true from this decision?

Comment 5

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

What about inputs with spellcheck=true?  If those are exempt too, then all spellcheckable inputs will be spellchecked on load, which reverts the UX improvement of spellcheck-on-focus.  But if they're not exempt, the use-case isn't satisfied for inputs, only for textareas.

In any event, if what authors want is fine-grained control over when spellcheck squiggles appear, we should give it to them in a standardized fashion.  Perhaps a new CSS property.  If any authors want to control this, they'll want to control it cross-browser, not just for Firefox, so I don't think we're adequately solving the problem if the solution isn't standardizable.

(The bug reporter here seems to be in a Firefox-only environment, but do we want to spend our resources optimizing for that?)

Comment 6

[(no longer active)]

(In reply to comment #5)
> What about inputs with spellcheck=true?  If those are exempt too, then all
> spellcheckable inputs will be spellchecked on load, which reverts the UX
> improvement of spellcheck-on-focus.  But if they're not exempt, the use-case
> isn't satisfied for inputs, only for textareas.

That is a fair point.

> In any event, if what authors want is fine-grained control over when spellcheck
> squiggles appear, we should give it to them in a standardized fashion.  Perhaps
> a new CSS property.  If any authors want to control this, they'll want to
> control it cross-browser, not just for Firefox, so I don't think we're
> adequately solving the problem if the solution isn't standardizable.

Not sure if we can use a CSS property to specify when something needs to happen.  The problem is that I can't really decide on what type of control do we want to provide the authors with here...

Comment 7

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

I'm honestly not clear on what the use-case is here, actually.  Chris, could you explain why you need spellcheck on init instead of on focus?  Is this just a matter of "this is how it used to work and we want to avoid retraining our users", or is there a specific reason why spellcheck on focus is a problem for your application no matter what?  I'm having trouble thinking of why it would be a problem -- it would help a lot with designing a solution if we had more details.  Thanks!

Comment 8

[Chris Jaure]

At my company, we have editors that review user-submitted content. The review page contains multiple fields and textareas. It's not an issue of retraining but of efficiency. The editors need to quickly spot and correct errors.

I'm not the only one with this use case: https://bugzilla.mozilla.org/show_bug.cgi?id=364914#c58

Comment 9

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

That seems like a valid use-case, yeah.  It could well occur in web apps, too.  So I think we want either a method that causes the textarea to be spellchecked immediately.  Testing in other browsers, the focus() workaround doesn't even work consistently, because IE and WebKit don't spellcheck until you actually modify the contents.  In fact, IE doesn't spellcheck words ever unless you modified that specific word!  I filed a spec bug:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19473

I suggested a new value like spellcheck="immediate".  I dunno what's best, though.  Maybe Hixie will have a stroke of genius.  I pinged him on IRC to look at it sooner rather than later, so maybe we'll get a reply now instead of months from now.

Comment 10

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19473#c3

Hixie suggests a .forceSpellCheck() method.  Does that sound good to everyone?

Comment 11

[Chris Jaure]

(In reply to :Aryeh Gregor from comment #10)
> Hixie suggests a .forceSpellCheck() method.  Does that sound good to
> everyone?

That's an acceptable solution for me.

Comment 12

[(no longer active)]

(In reply to comment #11)
> (In reply to :Aryeh Gregor from comment #10)
> > Hixie suggests a .forceSpellCheck() method.  Does that sound good to
> > everyone?
> 
> That's an acceptable solution for me.

Same here

Comment 13

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: PoC patch of forceSpellCheck

I chose the interface for ForceSpellCheck() according to Ms2ger's advice -- he wants it to match WebIDL bindings so that it's as easy as possible to port code to them when HTMLElement is converted.  The DOMForceSpellCheck variant is to be dropped at that point.  binaryname() is required here because the method is void and can't throw, so it differs only in return type from the XPCOM binding and can't be overloaded.  Click() is similar.

This doesn't handle contenteditable.  How does that work?  I couldn't find the code that lazy-spellchecks contenteditable, but from observation, we do in fact do that!

Things to test:

* <input type=text>, <textarea>, contenteditable
* Multiple editable areas in one page (forcing spellcheck of one should affect others)
* Called during load and after load
* Called on ancestors as well as the node itself (document.body.forceSpellCheck() will just force everything to be spellchecked)
* As I've implemented it, if an HTML element has a non-HTML child which has an editable HTML child, calling forceSpellCheck() on the ancestor shouldn't spellcheck the child -- this might be undesirable, but we should test whichever way we want it to be
* The method should not exist on non-HTML elements; this will be tested somewhat by IDL tests, since they'll verify that the method is an own property of the HTMLElement prototype and not the Element or Node prototype

I wish we had a better way to test this kind of thing than reftests.  They're really cumbersome for this sort of thing, and you can't really put them in HTML/DOM test suites because the way spellcheck is displayed isn't standard.  :(  On the other hand, we can't have a web-accessible API that exposes which words are marked as misspelled, for privacy reasons (user-specific dictionaries), so maybe there'd be no better way anyway.

Comment 14

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Oh, and just to reiterate what the patch says in a comment: obviously I won't check this in until it's in the spec!

Comment 15

[(no longer active)]

Comment on attachment 671196 [details] [diff] [review]
PoC patch of forceSpellCheck

Review of attachment 671196 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good overall.

For contenteditable stuff, the spell checker lives off of the nsHTMLEditor that is associated with the document.  I'm afraid that implementing this for contenteditable will make the code a bit complicated.. :(

About testing, I think reftests are the best way for now.  We also have tests which get the misspelled ranges and look at their content, etc. but I don't think that's a great way to test this.  And we definitely don't have a web-accessible API for this yet.

Comment 16

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

I don't think I'm going to continue work with this (unless Ehsan wants me to), so anyone else should feel free to pick it up.