Closed Bug 1139976 Opened 9 years ago Closed 8 years ago

Test test_keyboard_predictive_key.py is making wrong assumptions about how the internal dictionary works

Categories

(Firefox OS Graveyard :: Gaia::UI Tests, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: martijn.martijn, Unassigned)

References

()

Details

See bug 1121978, comment 16:
"
I really think it's sketchy to do a test based on assumptions about how the internal dictionary will correct. Is it context sensitive to what's already been typed in the past, making this possibly non-deterministic? Plainly it can make different decisions as we progress builds, and they're not bugs.

But if we do this, I think we need to take djf's bug 1121978, comment 3 to heart and quit trying to do this on three letter, ambiguous-in-English words. Just making it a string of multiple small words isn't going to fix that.

I think we should change this to a single, distinct English word for which there's only one reasonable completion when most of it is typed and no near-corrections. That's difficult because you need one that has no possible suffixes which might be displayed before the main word. That more or less limits it to idiosyncratic adverbs and semi-proper names that don't take regular plurals.

Try:

"edelw" --> only result should be "edelweiss"

That tests completion. If you want misspelling + completion:

"edels" --> only result should be "edelweiss"

Just misspelling:

"edelseiss" --> only result should be "edelweiss"

There are some other words that behave similarly (backstage is one I found) but "edelweiss" is the only one I found easily that becomes absolutely unique within a few keystrokes.
"


Bug 1121978, comment 3:
"
The predictions try to correct mistyping, and assume that the most likely typing errors are when the user presses a nearby key. So predictions are based on which keys are closest. And landscape and portrait keyboards have different dimensions and different key spacings. So what you're seeing is a side effect of that. Both 'he' and 'yes' seem like good corrections for 'ye', so I don't think this is a bug. 

I'd suggest that you work around it by finding a different test case (maybe a longer word) that autocorrects the same way in both orientations.  Or maybe by locking the orientation of the app so it runs consistently in the orientation you expect. Is there any way to do that with marionette? If automated tests are running in different orientations intermittently, this seems like it could be the source of other unexpected bugs.
"

I think I agree with this, there might definitely be better words to use for autocorrect.
Also, I think it would be great if we could use the autocorrect suggestion as the base to compare against the autocorrected word.
David, I would like your input on this. Do you agree about the proposed changes to this test? Or do you think this test is fine on itself?
Assignee: nobody → martijn.martijn
Flags: needinfo?(dflanagan)
I'm not really familiar with the test in question, but what you're proposing sounds very reasonable to me.
Flags: needinfo?(dflanagan)
Sorry, for some reason I thought you wrote the test.
Assignee: martijn.martijn → nobody
Marking WONTFIX, sorry for the bug spam. If somebody still wants to work on this, please file a new bug for it.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.