Closed Bug 888949 Opened 12 years ago Closed 12 years ago

input type="time" returns empty string when user inputs 00:00 to 00:59

Categories

(Firefox for Android Graveyard :: Keyboards and IME, defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox23 fixed, firefox24 fixed, firefox25 fixed)

RESOLVED FIXED
Firefox 25
Tracking Status
firefox23 --- fixed
firefox24 --- fixed
firefox25 --- fixed

People

(Reporter: imqqmi, Assigned: wesj)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release) Build ID: 20130511120803 Steps to reproduce: Using below html code yields a requester in android to pick a time: <form action="demo_form.asp"> Select your time: <input type="time" name="time"><br> <input type="submit"> </form> When time is set between 00:00 and 00:59, the android requester returns an empty string, ie the field in which you want to place 00:00 is empty. When you input 01:00 the field will get the correct '01:00' value. The same code is used in Chrome and the return value is as expected, a value between '00:00' and '00:59' instead of '' (empty string) which is the result in firefox for android. Actual results: An empty string is returned in the field. Expected results: The string should've been anything between 00:00 and 00:59 as set by the user.
OS: Windows 7 → Android
Hardware: x86_64 → ARM
OS: Android → Windows 7
Hardware: ARM → x86_64
OS: Windows 7 → Android
Hardware: x86_64 → ARM
I'm using Firefox on a Google Nexus 7 32GB on android v4.2.2
Component: General → DOM: Core & HTML
Product: Firefox for Android → Core
Version: Firefox 22 → Trunk
This might very likely be an Android widget issue according to comment 0. If setting "00:00" in the UI sets input.value to "", the DOM code can't do much against that. We should fix our widget implementation to not set the value to the empty string.
Component: DOM: Core & HTML → Keyboards and IME
Product: Core → Firefox for Android
Attached patch PatchSplinter Review
Android is returning a real string here. The problem seems to be that our date parsing expects hours in the range of 0-23: http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLInputElement.cpp#3714 and we're returning a date formatted with kk:mm, which is 1-24 hour time. http://docs.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html
Attachment #770011 - Flags: review?(mounir)
Comment on attachment 770011 [details] [diff] [review] Patch Review of attachment 770011 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for looking into is Wes :)
Attachment #770011 - Flags: review?(mounir) → review+
Assignee: nobody → wjohnston
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 25
Comment on attachment 770011 [details] [diff] [review] Patch This seems like a nice simple fix for Aurora at least, maybe Beta? [Approval Request Comment] Bug caused by (feature/regressing bug #): 781569 User impact if declined: Can't input times between 12am and 1am Testing completed (on m-c, etc.): Landed on mc today Risk to taking this patch (and alternatives if risky): This is pretty low risk. Just changes the date format returned by java to gecko to what gecko expects. String or IDL/UUID changes made by this patch: None.
Attachment #770011 - Flags: review-
Attachment #770011 - Flags: review+
Attachment #770011 - Flags: approval-mozilla-beta?
Attachment #770011 - Flags: approval-mozilla-aurora?
Attachment #770011 - Flags: review- → review+
Comment on attachment 770011 [details] [diff] [review] Patch simple low-risk fix, early enough in beta cycle we can take this.
Attachment #770011 - Flags: approval-mozilla-beta?
Attachment #770011 - Flags: approval-mozilla-beta+
Attachment #770011 - Flags: approval-mozilla-aurora?
Attachment #770011 - Flags: approval-mozilla-aurora+
Excellent work guys! Looking forward to v.23 and test my webapp to see if it indeed works as expected :)
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: