1239319 - Use the 'right' HTML input type attributes for the location bar and search bar to get a better on-screen keyboard for them on Windows

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[:Gijs (he/him)]

Right now we get the default keyboard. If we exposed InputScope IS_URL then we would get a nicer keyboard. TSFTextStore.cpp handles this based on input's type attribute. If we ensure the inner HTML input element has the right type attribute, we should be fine here.

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

It looks like we need to do something similar for the Search bar. If I click in the Search field of the Windows 10 Settings app, I get an on-screen keyboard with a magnifying glass as the Enter/Return key, whereas Firefox just shows the Enter/Return graphic on that button.

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Changing #searchbar's input to use type=search instead of type=autocomplete doesn't generate any different Firefox behavior that I can see, but it does show the Search glass on the OSK with this changed.

Comment 3

[:Gijs (he/him)]

It seems that the type="autocomplete" is required to get the right binding (autocomplete.xml) but then that's inherited onto the input element, where it has no meaning. We should support an extra attribute that we inherit there instead, probably something like "htmlinputtype", and then define it on the url and search bindings.

Comment 4

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 1239319 - use input types properly for search and url bar to get better OSK support on Windows, r?jaws

Review commit: https://reviewboard.mozilla.org/r/30981/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/30981/

Comment 5

[:Gijs (he/him)]

FWIW, I went with "inputtype" because we already have "inputtooltiptext", so that seemed the more consistent option.

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8708122 [details]
MozReview Request: Bug 1239319 - use input types properly for search and url bar to get better OSK support on Windows, r?jaws

https://reviewboard.mozilla.org/r/30981/#review27817

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/f427e163a304

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f427e163a304

Comment 9

[Matthew N. [:MattN]]

The URL bar attribute change was backed out in bug 1240181: https://hg.mozilla.org/mozilla-central/rev/71dec72dcdd5

Bug 1240208 covers finding an alternate solution for the keyboard layout while not causing bug 1240181.

Comment 11

[:Gijs (he/him)]

Attachment: Patch for beta

Approval Request Comment
[Feature/regressing bug #]: Windows on-screen keyboard support
[User impact if declined]: The keyboard doesn't adapt well for search fields in the browser (and/or: conflicts if we try to uplift bug 1240208)
[Describe test coverage new/current, TreeHerder]: no
[Risks and why]: very low, this is a minor change to XBL bindings used by Firefox for search and other input fields
[String/UUID change made/needed]: no.

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8716247 [details] [diff] [review]
Patch for beta

Improve the windows 10 support, taking it.
Should be in 45 beta 5

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/6cf32abc9a72

Comment 14

[Mayur Patil]

[bugday-20160323]

Status: RESOLVED,FIXED -> UNVERIFIED

Comments:
STR: Not clear.
Developer specific testing

Component: 
Name			Firefox
Version			46.0b9
Build ID		20160322075646
Update Channel          beta
User Agent		Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
OS			Windows 7 SP1 x86_64

Expected Results: 
Developer specific testing

Actual Results: 
As expected