Closed Bug 824148 Opened 7 years ago Closed 7 years ago
[KEYBOARD] Input type=range does not bring NUMBER keyboard
## Environment : Unagi phone, build ID 20121217070202 Installing Keyboard app UI and selecting Input type "RANGE" does not bring up "numbers" ## Repro: 1) Install Keyboard application UI from http://bit.ly/UgIMN4 on to the device 2) Click on the app "UI tests" from homescreen 3) Select "Keyboard test" from the "UI tests" list 4) Click On the input type = Range 5) Keyboard with text appears on screen ## Expected: Number Keyboard ## Actual: Keyboard with text characters Note: Test case #4794 mentions as "The keyboard "number" is opened"
This is related with moztrap test cases #4794 Please do fix this as I believe this is in v1 user story.
blocking-basecamp: --- → ?
OS: Windows 7 → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Triage: BB-, tracking-b2g18+. user can still switch to number keyboard manually.
Found on Unagi device Build ID: 20130104070203 v1.o
Assignee: nobody → margaret.leibovic
Attachment #700323 - Flags: review?(ttaubert)
Attachment #700323 - Flags: review?(ttaubert) → review+
Summary: [KEYBOARD] Input type= Range does not bring NUMBER keyboard → [KEYBOARD] Input type=range does not bring NUMBER keyboard
Comment on attachment 700323 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): n/a User impact if declined: input type=range shows wrong keyboard layout Testing completed: tested on local builds of inbound and b2g18, just landed on inbound Risk to taking this patch (and alternatives if risky): low risk String or UUID changes made by this patch: n/a
Attachment #700323 - Flags: approval-mozilla-b2g18?
UCID: owd-2922 https://moztrap.mozilla.org/results/case/63274/
Whiteboard: testrun 2
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Hi, This bug needed to be checked into b2g18 branches. Verified not fixed in 2013-01-20-07-02-02 b2g18 nightly pvt build.
Sorry, I don't have access to my ssh keys until I finish recovering my data, someone else will need to check this in (just ask in #b2g; backports aren't really a sheriff thing).
This change is not blocking-basecamp:+ or blocking-b2g:tef+, so we'll default to resolving in v1.0.1 first. You can either land on the date project branch already or wait for mozilla-b2g18 to be opened up to v1.0.1 changes.
We can just wait for mozilla-b2g18 to open to v1.0.1 changes. Will I be responsible for doing that, or will the status/tracking queries ensure this gets uplifted?
I still didn't see it in pvt build unagi 2013-2-4 Please do check-in for this change.
This needs approval before it can land: https://wiki.mozilla.org/Release_Management/B2G_Landing (Linked from the tbpl.mozilla.org tree status messages for the B2G trees, and on the newsgroups) Also, I believe RyanVM excludes B2G::Gaia* from his checkin-needed searches, since most require github (booo hissss!) checkin privs - so you'll need to needinfo? him explicitly once this has approval.
I look for all checkin-needed bugs regardless of component. It's just tef+/shira+/etc that I ignore Gaia on. But yeah, this needs approval before it can be uplifted to b2g18. Please add checkin-needed back when it gets it.
Comment on attachment 700323 [details] [diff] [review] patch Please go ahead with uplift to the tip of mozilla-b2g18 branch for v1.0.1
Attachment #700323 - Flags: approval-mozilla-b2g18? → approval-mozilla-b2g18+
Verified this issue has been fixed on unagi build 20130212070205 Dec 5th Kernel
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.