943690 - Autocorrection can't be turned off for specific input fields

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

Description

[Ben Bucksch (:BenB)]

Reproduction:
1. Make a webpage with a textfield <textarea autocorrect="off" />.
2. Start Firefox OS Simulator, open the page
3. Type "mt." with your computer's keyword.
4. Type "mt." with the virtual keyboard.

Actual result:
Step 3: "mt." stays, as it should.
Step 4: "mt." is being autocorrected into "my"

Expected result:
Step 3: "mt." stays
Step 4: "mt." stays

Comment 2

[Jan Jongboom [:janjongboom] (inactive)]

If this is also in 1.2 it should be koi+.

Comment 3

[Jason Smith [:jsmith]]

Note for the regression window - you can use marketplace's search bar as a way to test this. See the dupe's STR.

Comment 4

[Preeti Raghunath(:Preeti)]

Johnny,

Please check if this is a DOM issue.

Comment 5

[gbennett]

This issue has been occurring since one of the first flashable Leo 1.1 to the latest 1.2 builds, but does not repro on the latest 1.3. All relevant builds listed below.

Environmental Variables:
Device: Leo 1.1 comRIL
BuildID: 20130805231203
Gaia: 271fb7204c3d8c2a52d69e1c0e6aa4d7414b9fa8
Gecko: a2a9b89ef5ee
Version: 18.0
Firmware Version: V10d

Environmental Variables:
Device: Buri 1.2 comRIL
BuildID: 20131127004001
Gaia: 92cd11ea023dd6598d82d859ae3c945ff6589ce6
Gecko: 14e91ab12441
Version: 26.0
Firmware Version: 20131115

Environmental Variables:
Device: Buri 1.3 mozRIL
BuildID: 20131127040203
Gaia: d4b9a3d271f0451b4d903a03c2b931b8cc092041
Gecko: 6ecf0c4dfcbe
Version: 28.0a1
Firmware Version: 20131115

Comment 6

[Jason Smith [:jsmith]]

Reduced test case is here: http://jsbin.com/UdOGIpA/1

The above regression window is incorrect - this was reproducing on yesterday's build, so I very strongly doubt the above testing is valid. Please recheck this using the reduced test case.

Comment 7

[Jason Smith [:jsmith]]

I just checked this directly myself. I saw this reproducing on the latest 1.2 build & yesterday's 1.3 build.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #7)
> I just checked this directly myself. I saw this reproducing on the latest
> 1.2 build & yesterday's 1.3 build.

I can't reproduce this on a 1.1 10/1 build.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #8)
> (In reply to Jason Smith [:jsmith] from comment #7)
> > I just checked this directly myself. I saw this reproducing on the latest
> > 1.2 build & yesterday's 1.3 build.
> 
> I can't reproduce this on a 1.1 10/1 build.

Wait, I see the bug now on 1.1. Weird - I thought this bug was fixed. Apparently it wasn't. It probably didn't block any operator because every operator turned off auto-correction by default, so the UX impact wasn't ever apparent.

This is clearly incorrect behavior. However, given that we know operators turn off auto-correction by default, I don't think we can block on this.

Comment 10

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

I don't think we support autocorrect="off" for Gaia built-in keyboard app.
So, this is not a regression, because this is never implemented.

Is "autocorrect" a standard that we sould support now?

Comment 11

[Ben Bucksch (:BenB)]

It doesn't really matter how it's called, but it's necessary for authors to specify that spellchecking/autocomplete/autocorrect are going to go wrong in this usecase and for the content usually added in that particular field, and to turn autocorrect off.

Examples:
* Username field
* Names
* Firefox marketplace app search
* Fields that contain abbreviations or special terms of a domain
The list of fields where autocorrect will go wrong is endless. Basically everything that isn't long, normal prose text.

Comment 12

[(no longer active)]

We don't implement autocorrect, so this is not a regression.  That is an Apple proprietary API.  If you think this attribute is useful, please send a proposal to whatwg.  Thanks!

Comment 13

[Jason Smith [:jsmith]]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #12)
> We don't implement autocorrect, so this is not a regression.  That is an
> Apple proprietary API.  If you think this attribute is useful, please send a
> proposal to whatwg.  Thanks!

We need a solution here at the DOM level. The marketplace team is blocked here having a useful search experience with auto-correction enabled, as auto correct is correcting search terms that shouldn't be corrected.

Comment 14

[(no longer active)]

(In reply to Jason Smith [:jsmith] from comment #13)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #12)
> > We don't implement autocorrect, so this is not a regression.  That is an
> > Apple proprietary API.  If you think this attribute is useful, please send a
> > proposal to whatwg.  Thanks!
> 
> We need a solution here at the DOM level. The marketplace team is blocked
> here having a useful search experience with auto-correction enabled, as auto
> correct is correcting search terms that shouldn't be corrected.

Can you please help me understand why this is a problem specific to the marketplace and not other web pages?

Comment 15

[Jason Smith [:jsmith]]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #14)
> (In reply to Jason Smith [:jsmith] from comment #13)
> > (In reply to :Ehsan Akhgari (needinfo? me!) from comment #12)
> > > We don't implement autocorrect, so this is not a regression.  That is an
> > > Apple proprietary API.  If you think this attribute is useful, please send a
> > > proposal to whatwg.  Thanks!
> > 
> > We need a solution here at the DOM level. The marketplace team is blocked
> > here having a useful search experience with auto-correction enabled, as auto
> > correct is correcting search terms that shouldn't be corrected.
> 
> Can you please help me understand why this is a problem specific to the
> marketplace and not other web pages?

Well, actually this problem could happen more generally across the web. I think the marketplace use case was just the more prominent use case known because it was impacting their search experience (i.e. they want the ability to disable auto correct on a search bar in the web even if auto-correction is enabled on the phone, so that a term a user provides isn't accidentally auto-corrected to something they didn't want to search for).

Comment 16

[(no longer active)]

(In reply to comment #15)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #14)
> > (In reply to Jason Smith [:jsmith] from comment #13)
> > > (In reply to :Ehsan Akhgari (needinfo? me!) from comment #12)
> > > > We don't implement autocorrect, so this is not a regression.  That is an
> > > > Apple proprietary API.  If you think this attribute is useful, please send a
> > > > proposal to whatwg.  Thanks!
> > > 
> > > We need a solution here at the DOM level. The marketplace team is blocked
> > > here having a useful search experience with auto-correction enabled, as auto
> > > correct is correcting search terms that shouldn't be corrected.
> > 
> > Can you please help me understand why this is a problem specific to the
> > marketplace and not other web pages?
> 
> Well, actually this problem could happen more generally across the web. I think
> the marketplace use case was just the more prominent use case known because it
> was impacting their search experience (i.e. they want the ability to disable
> auto correct on a search bar in the web even if auto-correction is enabled on
> the phone, so that a term a user provides isn't accidentally auto-corrected to
> something they didn't want to search for).

Please see the dev-webapi thread.  I don't think that the requirements here are quite clear cut.  We need to work on that first.  Once we have that figured out, we need to make sure that this is something that the user can opt out of in an easy way, since it could be that the website author is wrong, and the user does in fact want auto correction to happen.  Then we need to submit a proposal to whatwg and see if others are interested in implementing it.

Comment 17

[Ben Bucksch (:BenB)]

(In reply to Ben Bucksch (:BenB) from comment #11)
> The list of fields where autocorrect will go wrong is endless. Basically
> everything that isn't long, normal prose text.

This leads me to:
Bug 944657 - Disable autocorrect for <input>, but leave it on for <textarea>

However, please note that Bug 944657 would *not* help my usecase, because I have a <textarea> that must contain a lot of abbreviations, and they are mangled and destroyed by autocorrect, making the field entirely useless for the end user.

Comment 18

[Ben Bucksch (:BenB)]

Ehsan,

can you explain why you think this concerns DOM/Gecko? I've never encountered this problem in desktop Firefox, ever. We don't have this problem there, so there's no action to be taken there.

Also, note that Firefox OS in principle doesn't have a problem. See the reproduction steps closely. It's only the virtual keyboard that causes the problem.

What I imagine as implementation is that the Gaia virtual keyboard would, when it opens on a certain input field, check whether the DOM attribute "autocorrect" on it is set, and then turn off its own autocorrection. Given that DOM read access is generic, there's no support in the DOM or in Gecko at all needed, the change is purely in the Gaia Virtual Keyboard.

If you're concerned to establish an unwanted quasi-standard, you might want to call it "moz-autocorrect".

Ehsan, does that address your concerns?

Comment 19

[Ben Bucksch (:BenB)]

FWIW: As a user, I totally hate autocomplete="off", and I wish we didn't support that. This isn't the same, though. Autocomplete is predictable and works. Autocorrection is a heuristic that doesn't work in many cases. The page author is (after the user) in the best position to say where it works and where not, better than any heuristic that we can come up with, so this is a good thing to add.

Comment 20

[(no longer active)]

(In reply to Ben Bucksch (:BenB) from comment #18)
> Ehsan,
> 
> can you explain why you think this concerns DOM/Gecko? I've never
> encountered this problem in desktop Firefox, ever. We don't have this
> problem there, so there's no action to be taken there.
> 
> Also, note that Firefox OS in principle doesn't have a problem. See the
> reproduction steps closely. It's only the virtual keyboard that causes the
> problem.
> 
> What I imagine as implementation is that the Gaia virtual keyboard would,
> when it opens on a certain input field, check whether the DOM attribute
> "autocorrect" on it is set, and then turn off its own autocorrection. Given
> that DOM read access is generic, there's no support in the DOM or in Gecko
> at all needed, the change is purely in the Gaia Virtual Keyboard.
> 
> If you're concerned to establish an unwanted quasi-standard, you might want
> to call it "moz-autocorrect".
> 
> Ehsan, does that address your concerns?

Not really.  No matter where you're proposing this change to be implemented, it _is_ a web facing change, so we should take the proper care in exposing this feature, as we would while implementing any other web facing feature.

Here are my objections to implementing "autocorrect":

1. It doesn't have a proper spec.
2. It is not a "de-facto" standard in any way, it's *only* implemented in iOS Safari as far as I can tell.
3. It is subsumed by @inputmode.

Therefore, I would suggest that we should wontfix this bug.  If you disagree, please let me know what I'm missing in my objections above.

Thanks!

Comment 21

[Jason Smith [:jsmith]]

The main objection I have here falls in alignment with the discussion that happened on https://bugzilla.mozilla.org/show_bug.cgi?id=921014#c11 - we have to make an accurate assessment of whether there exists a compatibility concern to warrant implementation of this. I think we need data similar to what happened on that bug to determine what to do here.

Comment 22

[Ben Bucksch (:BenB)]

Ah. If you know a better standard, then by all means, let's use that one.

The only thing I care about and that this bug is about that the page author can say for a specific input field: "Dear browser, don't bother with autocorrection, it will go wrong, due to the nature of the data in this field"

I've adapted the summary to be more generic

Comment 23

[(no longer active)]

(In reply to Ben Bucksch (:BenB) from comment #22)
> Ah. If you know a better standard, then by all means, let's use that one.
> 
> The only thing I care about and that this bug is about that the page author
> can say for a specific input field: "Dear browser, don't bother with
> autocorrection, it will go wrong, due to the nature of the data in this
> field"

Why can't you use x-inputmode?

Comment 24

[(no longer active)]

(In reply to Jason Smith [:jsmith] from comment #21)
> The main objection I have here falls in alignment with the discussion that
> happened on https://bugzilla.mozilla.org/show_bug.cgi?id=921014#c11 - we
> have to make an accurate assessment of whether there exists a compatibility
> concern to warrant implementation of this. I think we need data similar to
> what happened on that bug to determine what to do here.

If we have evidence that this is a generic web compat concern, I agree that we should re-evaluate, but in concert with other engines.  I thought that we're talking about the marketplace app here though.

Comment 25

[Jason Smith [:jsmith]]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #24)
> (In reply to Jason Smith [:jsmith] from comment #21)
> > The main objection I have here falls in alignment with the discussion that
> > happened on https://bugzilla.mozilla.org/show_bug.cgi?id=921014#c11 - we
> > have to make an accurate assessment of whether there exists a compatibility
> > concern to warrant implementation of this. I think we need data similar to
> > what happened on that bug to determine what to do here.
> 
> If we have evidence that this is a generic web compat concern, I agree that
> we should re-evaluate, but in concert with other engines.  I thought that
> we're talking about the marketplace app here though.

Karl - Can you find out how often the autocorrect attribute is used across the mobile web? I'm trying to get a picture if there's a compatibility risk with not supporting it.

Comment 26

[Ben Bucksch (:BenB)]

> Why can't you use x-inputmode?

I just tried <textarea x-inputmode="verbatim"/>, and it's working fine. Thanks!

I couldn't find this on my own: Google's first hit for "x-inputmode" is a gamepad, and for "x-input-mode", it's only about gamepads, and searching for "autocorrect off" (which is what I was searching for naturally) doesn't find it at all. If you wouldn't have told me, I wouldn't know about it. So, this helps me, but nobody else.

I understand that standardization is slow, but we need this attribute before the autocorrect feature is enabled in Firefox OS. Given that it's already enabled, we'd need this yesterday. I know: impossible :-(

Not sure what to say here, apart from: We need a solution for authors, and they need to know about it.

Comment 27

[Ben Bucksch (:BenB)]

(In reply to Preeti Raghunath(:Preeti) from comment #4)
> Johnny, Please check if this is a DOM issue.

I think ehsan answered that. (If you disagree, please re-request.)

Comment 28

[Karl Dubost💡 :karlcow]

So I have finished to read this thread

(In reply to Jason Smith [:jsmith] from comment #25)
> Karl - Can you find out how often the autocorrect attribute is used across
> the mobile web? I'm trying to get a picture if there's a compatibility risk
> with not supporting it.

I have seen 4 things discussed along the thread:

* spellchecking
* autocorrect  off/on
* autocomplete  off/on
* x-inputmode="verbatim"

In iOS documentation, there are two attributes: autocorrect="on" and autocapitalize="on"
https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/DesigningForms/DesigningForms.html#//apple_ref/doc/uid/TP40006512-SW2
with the following explanation

> Set the autocorrect attribute to on if you want automatic correction 
> and the autocapitalize attribute to a value if you want automatic 
> capitalization. If you do not set these attributes, then the browser 
> chooses whether or not to use automatic correction or capitalization. 
> For example, Safari on iOS turns the autocorrect and autocapitalize 
> attributes off in login fields and on in normal text fields.

The details of the attributes are given on 

* autocapitalize: 
https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html#//apple_ref/doc/uid/TP40008058-autocapitalize

none, sentences, words, characters (available in iOS5+)
off, on (deprecated in iOS5+)

* autocomplete:
https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html#//apple_ref/doc/uid/TP40008058-autocomplete
off, on (only on input)

* autocorrect:
https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html#//apple_ref/doc/uid/TP40008058-autocorrect
off, on

There's the inputmode attribute, but which seems completely orthogonal to autocompletion and autocorrection in the current definition. I created a bug.
http://www.w3.org/html/wg/drafts/html/master/forms.html#input-modalities:-the-inputmode-attribute
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23953


The current mozilla documentation is even less clear. It doesn't define anything for inputmode.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLTextAreaElement#Properties

Following your nose, you may find.
* Firefox OS 1.2 for developers
  https://developer.mozilla.org/en-US/Firefox_OS/Releases/1.2
* with a link to "window.navigator.mozInputMethod"
  https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozInputMethod
* with a link to "mozInputMethod API to Keyboard Apps"
  https://wiki.mozilla.org/Talk:WebAPI/KeboardIME#mozInputMethod_API_to_Keyboard_Apps

but it still doesn't explain what it does. 

In Firefox 21 release notes, it says it has been disabled by default.
https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_21#DOM

In Chromium/Blink Bug, we can find the link to Gecko and Webkit
https://code.google.com/p/chromium/issues/detail?id=244688
https://bugzilla.mozilla.org/show_bug.cgi?id=746142
https://bugs.webkit.org/show_bug.cgi?id=23588

It seems currently that Chrome doesn't support any of the following attributes.
https://code.google.com/p/chromium/issues/detail?id=303883&q=autocorrect&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

> * autocomplete="on" 
> * autocorrect="on" 
> * autocapitalize="on" 
> * spellcheck="true"


Is it implemented elsewhere than iOS?

IE 10 has a spellcheck attribute
http://msdn.microsoft.com/en-us/library/ie/hh801220%28v=vs.85%29.aspx

It seems to be a giant mess around this topic :)

Comment 29

[Jason Smith [:jsmith]]

So from what I understand above, there's a lot of inconsistency across the web on how auto-correction & related attributes operates across the web, so we need to get consistent story clear here.

As for this bug, I'm going to close this out now with Karl's feedback with Ehsan's request as I think implementing this out right isn't way to go, as this approach doesn't have a consistent web story right now.

Comment 30

[Ben Bucksch (:BenB)]

Sorry, The need exists and is real. Autocorrect breaks my webapp (or rather, the typical input that users make there).

But if there isn't a clear story, then we need to make it clear. Either way, it needs to be solved. And soon.

Comment 31

[Jan Jongboom [:janjongboom] (inactive)]

I'm with Ben on this.

Comment 32

[(no longer active)]

(In reply to Ben Bucksch (:BenB) from comment #30)
> Sorry, The need exists and is real. Autocorrect breaks my webapp (or rather,
> the typical input that users make there).
> 
> But if there isn't a clear story, then we need to make it clear. Either way,
> it needs to be solved. And soon.

If I read comment 26 right, all you're asking for is better documentation on x-inputmode.  In that case, please file a new bug against MDN for that.  I don't understand what else needs to be done here.  "Autocorrect breaks my webappp" isn't really actionable.  :-)

Comment 33

[Ben Bucksch (:BenB)]

But I'm a little confused. *My* immediate problem is solved, yes. Karl said the story is unclear, you're saying I should clearly used x-inputmode. Whatever - as long as our story is clear and public and reasonable. Because I won't be the only one with that problem, and I want it to be solved for everybody, not just me.

Comment 34

[(no longer active)]

(In reply to comment #33)
> But I'm a little confused. *My* immediate problem is solved, yes. Karl said the
> story is unclear, you're saying I should clearly used x-inputmode. Whatever -
> as long as our story is clear and public and reasonable. Because I won't be the
> only one with that problem, and I want it to be solved for everybody, not just
> me.

I'm trying to understand what you're proposing that we should do here.  I'm not sure why x-inputmode should not be enough to address other people's needs here.

Comment 35

[Ben Bucksch (:BenB)]

1. concretely define the values of x-inputmode
   They are a bit blurry (and that was the feedback Mozilla got
   when this was proposed as standard).
2. document it
   * clearly, and complete and
   * can easily be found by typical Google searches
3. standardize it and make other browsers implement it

(Personally, I prefer the autocorrect="off" attribute, because it's clearer and already well-established, but that's just me.)

Part 3 will obviously take time. Part 1. and 2. must happen before we can consider this issue to be resolved to some degree.

Comment 36

[(no longer active)]

(In reply to comment #35)
> 1. concretely define the values of x-inputmode
>    They are a bit blurry (and that was the feedback Mozilla got
>    when this was proposed as standard).

Not sure which specific vagueness you're talking about here.

> 2. document it
>    * clearly, and complete and

Like I said, please file a bug in MDN for that.

>    * can easily be found by typical Google searches

I doubt that we can do anything to affect that besides just documenting the attribute.

> 3. standardize it and make other browsers implement it

Please see <http://www.w3.org/html/wg/drafts/html/master/forms.html#inputmode-1>.

If you think there is anything in the spec which is not clear, please file a bug with the spec.

Thanks!

Comment 37

[Ben Bucksch (:BenB)]

> Not sure which specific vagueness you're talking about here.

Where's the authoritative and complete list on
1) which values the attribute can have
2) what they mean, what they are for
3) which effect they will have in practice in the browser?

All I found is http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-inputmode
But:

A) It doesn't answer question 3) above

This seems to be the root of Jonas' feedback, too:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org//2013-February/038949.html

B) Spec is not sound:
Latin and kana are orthogonal to things like "autocorrect off".
Likewise, "email" belongs in type, and is already standardized and accepted cross-browser there, but inputmode has it as well - again: orthogonal.
So, the current spec has 3 or more orthogonal aspects in the same field:
1. script/language (latin, kana...)
2. data type (text, numbers, email, url)
3. typing aids
3.1. completion / text prediction
3.2. correction
3.3. capitalization
3.4. spell checking

They are orthogonal, because I can have completion, correction and even capitalization for names (using the user's address book) and for text (using a dictionary). They'd use different algorithms, but still the type (name, text) is a different aspect from whether I want the computer helping my type or not.

That all doesn't seem well-thought out, and Mozilla thinks so, too:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org//2013-February/038914.html

This whole definition of inputmode seems off, because in my usecase, it is actually "prose" text that the user enters. But the prose contains special abbreviations and terms that I need to recognize, and Firefox OS' autocorrect wrongly "corrects" these, too, rendering this form and app feature useless. So, I actually *do* want to say that it's "prose" text (inputmode="prose"), I just want to tell Firefox OS to get out of the way. An autocorrect="off" seems like a much better way to turn off one specific malfunctioning feature than saying inputmode="verbatim", which would disable all typing aids. I have nothing against "Swipe" (on Android) or even the autocomplete suggestions that Firefox OS shows in the row above the virtual keyboard.

Comment 38

[Ben Bucksch (:BenB)]

> please file a bug with the spec

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

Comment 39

[(no longer active)]

Thanks for filing the spec issue.  I don't have much else to add here, I'm afraid.

Comment 40

[Karl Dubost💡 :karlcow]

(In reply to Ben Bucksch (:BenB) from comment #38)
> > please file a bug with the spec
> 
> Done:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23961

Cough cough, some people didn't read comment #28 ;)
I had done it https://www.w3.org/Bugs/Public/show_bug.cgi?id=23953

Eventually it will be closed as a duplicate. :)

Comment 41

[Karl Dubost💡 :karlcow]

I tested a few things http://www.la-grange.net/forms
You are welcome to add more browsers/platforms :). 

I will write a blog post with my findings

Comment 42

[(no longer active)]

(In reply to comment #41)
> I tested a few things http://www.la-grange.net/forms
> You are welcome to add more browsers/platforms :). 
> 
> I will write a blog post with my findings

Karl, mobile Safari is the only browser implementing autocorrect and autocapitalization.  Firefox OS is the only browser implementing x-inputmode.  I don't think anybody else implements inputmode at this point.

Comment 43

[Karl Dubost💡 :karlcow]

yes. You can add spellcheck for IE.
After testing I don't think inputmode is the right answer for disabling autocomplete and autocorrect.

Comment 44

[Ben Bucksch (:BenB)]

Reopen based on comment 37.

Comment 45

[BMO Automation]

Firefox OS is not being worked on