In https://bugzilla.mozilla.org/show_bug.cgi?id=861108#c9, Evelyn points out what I think is a bug in the code I landed for https://bugzilla.mozilla.org/show_bug.cgi?id=860462 In detecting words, I need to ensure that I'm not treating punctuation as part of a word, or I'll send nonsense prefixes to the prediction engine and tie up the CPU.

After further discussion in bug 861108, it occurs to me that since the prediction engine now has a table of all characters in the dictionary, it should do a quick first pass through the input text to verify that all charactesr in the input appear in the dictionary. If they don't then there is nothing to predict. (Or, as a slightly less severe restriction, we could require that each character is in the dictionary or is in the keyboard layout with nearby keys that are in the dictionary.)

Adding whiteboard tags for tracking via srumbu.gs.

Preemptively asking for leo+ all the bugs blocking the keyboard auto-correct umbrella bug 797170.

email sent to David requesting more info on why these are nominated when the meta bug is not leo+

seem like a product/UX decision whether we need auto-correct in 1.1

Chris is driving keyboard improvement decisions.

Fixed by parent bug 865484. In addition to the valid characters check described in comment 1, that bug also adds a length check: if the input is longer than the longest word in the dictionary, we return immediately with no suggestions.

Tracking since this change is wanted by UX but quality of fix needs to be assessed before decision to uplift. See below: On 5/7/13 12:03 AM, Christopher Lee wrote: Thanks Francis. Sounds like you and Josh are going to review the latest patches from David tomorrow and provide an assessment on the quality. I'm also going to get a build tomorrow and evaluate the latest changes and we can collectively make a call on if it's ready for uplift.

Uplifted to v1-train in bug 873934