jQM text input forces use of iOS auto-correction #785

Closed
jameskoch opened this Issue Jan 10, 2011 · 25 comments

Projects

None yet

9 participants

@jameskoch

1) Using an iOS 4 device visit Demos > Form Elements > Form Element Gallery.
2) In the first text input, mis-spell something. Like "Automibile".

3) iOS suggests "Automobile".
4) Assume you actually wanted the incorrect version. Try to click the X in order to NOT accept the auto-correction. You can't.

This is an issue for text inputs used for login forms, since auto-correct often kicks in and tries to auto-correct usernames and domain names.

@toddparker

Odd. I was able to reproduce this on the form gallery and the input sample page. The strange thing is that this is just the native input with some light styling. If you have time to dig into this and figure out what's giving us trouble, please post it here. We're thinking it must be a CSS issue.

@jblas

Hmmm, this looks like a bug in IOS. If the ancestor of the text input just listens for touchstart, you can repro this bug:

<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width, user-scalable=no">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Issue 785</title>
<style type="text/css">
#textfield-ancestor {
    width: 300px;
    height: 300px;
    border: solid 1px black;
    background-color: #FF9;
    padding: 10px;
}
</style>
<script type="text/javascript">

function init()
{
    document.getElementById("textfield-ancestor").addEventListener("touchstart", function(e){}, false);
}

</script>

<body onload="init();">
<div id="textfield-ancestor">
    <input id="textfield" type="text" value="Auto">
</div>
</body>
</html>
@jblas

I filed the issue with Apple:

Problem ID: 8910589

@toddparker

That's bad news. Is there a way to work around this bug?

@jameskoch

For my login field I added all of the following attributes to totally avoid any sort of iOS magic, including the problematic autocomplete: autocapitalize="off" autocorrect="off" autocomplete="off"

@jblas

@toddparker

I haven't been able to figure out a workaround yet. The touch event passes right through the autocorrect pop up to the ancestor below it. If you click into some other text input to take focus away, it disappears, but it also replaces your text with whatever text was in the pop up.

@jblas

I just checked in a temporary workaround for iOS only that disables the autocorrect feature on all inputs of type="text":

63a8296

Todd, do we want to reduce the severity so that it isn't a blocker anymore?

@toddparker

Thanks Kin. I just moved this down to high priority and took you off the assignment. You can look at this again if/when Apple fixes that bug!

@Brons

Is there, by any chance, any news on this from Apple, or any better work-around? The app we are working on involves a lot of text input and having autocorrect disabled is a decided disadvantage.

Thanks

@whatbird

what a drag. i'd love to see this issue go away. wrapping browser bugs like this should be part of the mission. AutoFill is a must for a conversion-focused mobile app.

now, i'm going to bang my head on this wall for a bit.

@toddparker

Hey guys, we totally agree that this should be fixed and we'd be happy to include a workaround if we could find one. The problem is that issues submitted to APple go into a black hole with no visibility so we'll never know what their plans are on this one. Keep looking for a workaround and let us know what you find.

@parker21

The fix for this causes Safari Mobile not to prompt to save usernames and passwords. See my comment to this thread.

http://forum.jquery.com/topic/browser-does-not-ask-to-remember-password

@jblas

UPDATE:

I was pinged by Apple to test for this problem on iOS5 beta 5. The good news ... I couldn't reproduce the problem so it seems like this problem will go a way when folks upgrade to iOS5.

So now the question is, do we leave the workaround in place and detect for old versions of iOS?

@zhubert

So is it currently the case that we're unable to offer autocorrect='on' to our iOS users for the many text_fields where they really want them?

@scott-vs

Am I the only one who thinks that the workaround is causing more user annoyance than the original issue did?

When I'm typing really fast on the iOS keyboard, I never attempt to cancel the autocorrect suggestion by clicking on the X, it interrupts the flow. I'm used to having the correction go through, then deleting the word and re-typing what I wanted it to be.

In my opinion, not having the autocorrect enabled at all makes typing on any jQM page practically unusable.

@toddparker

Well, without disabling autocorrect, you couldn't dismiss the suggestion so you were forced to accept it which seems much more annoying than living without it. Like @jblas said, this issue should go away with iOS 5 but we'd need to figure out how to target this attribute to iOS4 and older and leave it off in 5.

@jblas jblas was assigned Sep 9, 2011
@toddparker

Re-prioritized this as low since we have a workaround (disabling auto-correct), but I'd like to find a way to not disable this on iOS5 if it's fixed there. @jblas - ideas?

@jblas

@toddparker, how is @scottjehl detecting ios5 for the -webkit-overflow-scroll property?

@toddparker

Good idea @jblas, we could use support for -webkit-overflow-scrolling:touch to not apply this hack so iOS will get the correction suggestions again. Maybe not the best long-term solution, but good for now. Want to give it a try?

@toddparker

I'm moving the iOS5 targeting as somethign we should try to land for 1.0

@scottjehl

jblas - it's a support test for the CSS property's existence. It's not a webkit-specific test, so it's possible it'll target more than ios5 one day. Maybe fine to use for this though. $.support.overflowScrollingTouch

@jblas

@scottjehl

Yeah, I looked into it on Friday ... I feel so dirty using that as the test ... hence my hesitation to land anything yet. :-)

@toddparker

@jblas - Agreed, it's a bit ugly but the workaround was pretty heavy-handed in the first place so if we can get this working again for iOS5, despite the odd targeting, let's go for it.

@jblas

@toddparker @scottjehl

I just landed the check to disable the workaround for iOS 5:

a975878

Not sure what to do about this bug now. I'm not sure Apple is going to back-port the fix to any 4.x or earlier iOS.

As a sidenote, 3 of us (@jblas, @toddparker, @gseguin) verified that the original bug is fixed in iOS 5 using the test case I submitted to Apple. We were all able to dismiss the suggestion popup by tapping on it. I did a quick test in the emulator with a jQuery Mobile page and successfully dismissed it under iOS 5.

@toddparker

I think that we should probably close this because it's as fixed as it can be right now. If they backport a fix (very unlikely), we can remove the iOS 4 workaround.

@toddparker toddparker closed this Sep 26, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment