Closed Bug 1083633 Opened 5 years ago Closed 4 years ago
Remove x-inputmode="verbatim" from home search / e
46 bytes, text/x-github-pull-request
|Details | Review|
By bug 898352, x-inputmode="verbatim" is added to search input box. According to http://www.w3.org/html/wg/drafts/html/master/forms.html#input-modalities:-the-inputmode-attribute, verbatim is the following "Alphanumeric Latin-script input of non-prose content, e.g. usernames, passwords, product codes." If this field is for username, it is OK, But search box should allow non-latin character such as Kanji due to search box. So I think that we should remove x-inputmode="verbatim" from this.
The search box on homescreen should allow non-latin string. If IME looks x-inputmode correctly, it can input latin character only is x-inputmode="verbatim". (built-in keyboard doesn't check it correctly yet.)
Assignee: nobody → m_kato
Attachment #8505986 - Flags: review?(crdlc)
Comment on attachment 8505986 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/25205 LGTM but I would like a double check here
Thank you for your contribution Makoto. I am not 100% sure if we want to do this - only because if we do, I think we get the keyboard with auto-correct, which we don't want for english. I'm adding some keyboard experts here to get their opinion. Tim, Rudy - What do you guys think? Is there a better way to disable auto-correct for english than inputmode="verbatim"?
Not saying Keyboard app is exactly following the spec, but latin IME decide whether or not to give out correction/suggestion here: https://github.com/mozilla-b2g/gaia/blob/master/apps/keyboard/js/imes/latin/latin.js#L198-L200 So for your question, no, there is no way to disable auto-correct for english than inputmode="verbatim". I actually don't know the reason why we shouldn't be auto-correcting in search boxes. I am all ears to hear about what we can change in the behavior of keyboard app to inputmodes.
The "search box" is also the URL bar, so it's a bit weird to have auto-correct popping up there when you are entering in a URL. Also the search suggestions screen gets a little too messy when you have search suggestions, local results, and also keyboard suggestions popping up. It sounds like to fix this we would need another hook for auto-correct in this case, so I'll file a bug to do so now.
Comment on attachment 8505986 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/25205 Thank you very much for the patch. While this looks good, I think we unfortunately need to wait until bug 1084186 has a solution before we can land this. I will go ahead and clear reviews, and once we have a solution for bug 1084186 we can revisit this. Please re-request review if you feel differently.
(In reply to Kevin Grandon :kgrandon from comment #5) > The "search box" is also the URL bar, so it's a bit weird to have > auto-correct popping up there when you are entering in a URL. Also the > search suggestions screen gets a little too messy when you have search > suggestions, local results, and also keyboard suggestions popping up. > > It sounds like to fix this we would need another hook for auto-correct in > this case, so I'll file a bug to do so now. This is probably an UX question: if the box serves two purposes, which one is more preponderant so turning on auto correction is more useful and otherwise? I do love typing URLs and I remember a few complex ones, but the most user would not in the mobile world. I won't mind if typing URL is a bit cranky but make typing search terms more useful. Alternatively we could do something intelligent in the application code -- providing two input boxes underneath in rocket bar, 1) When the user focused on the empty box, she/he would get <input type="search"> 2) When she/he types "www", or any word that end with ".", copy the typed text and quietly move the focus to an <input type="url">. We can try to change the type attribute of the same input box but I am not sure Input Method API will respond well to that -- something we could fix if you want to.
Mass update: Resolve wontfix all issues with legacy homescreens. As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.