BB10 input[type=date] and datepicker - html

I'm working on bug requests for an jQuery Mobile/HTML5 app on Blackberry 10. One of the bugs reported only seems to manifest on the BB10. The bug report is that the datepicker sometimes doesn't show up when the date field (input type=date) is tapped.
After experimenting with this for a while, it appears that, on the BB10, the date picker isn't triggered by the date field having focus, but rather by the the user 'tapping' the field -- and that tap seems to have a bit of time sensitivity.
As an example: if I use jQuery Mobile's "clear button", like so:
<input type="date" name="my-field" value="" data-clear-btn="true" autocorrect="off"
autocapitalize="off" />
I can easily create a scenario where I provide a date and then hit the clear button. The net result is that the date field has focus, but the date picker doesn't automatically appear. Once the form state is like this, it's pretty easy to get the problematic behaviour -- tap and nothing happens.
As I said, above, there seems to be a bit of time sensitivity to the tapping. When trying to give that field focus, some people seem to tap fairly quickly -- jQuery seems to notice the tap and does its magic to apply the "ui-focus" style, but it's still seems to be too quick to get the date picker to intervene. So far, every time I've held my finger down for a full second, I've always had the date picker pop up, but my usual tapping speed is a bit too fast to trigger the date picker (and the QA people certainly seem to have tripped on this a number of times).
My question, then, is: Is there anything I can do about this? Is there an event I can fire on focus that'll trigger the datepicker? Or some kind of configuration I can fiddle with?
I fear that the answer is probably "no" but I wanted to ask.

Related

"type" value into input date field with puppeteer

I'm trying to simulate with puppeteer a user entering a value into an input date field (eg <input type="date" />), but I'm experiencing different behaviour than when a human actually does this. I'm not sure if this is a bug in Puppeteer or if I'm doing something wrong.
Everywhere I've found saying how to enter the value suggests merely page.keyboard.type(selector, value), but when I do that, nothing gets entered (but it looks like it's trying):
(animated GIF, cuz SO won't let me add the video. beware the GIF is real annoying)
Alternatively, I tried first selecting the field, and then using elementHandle.type(value), which at least does something, but the value entered is jumbled nonsense:
(animated GIF, cuz SO won't let me add the video. beware the GIF is real annoying)
One strange thing is that when Puppeteer focuses the field (via Tab key), yyyy is selected; but when I human does it, dd is selected.
I also tried slicing the value up and manually setting each "piece", but that results in the same behaviour as elementHandle.type(value).
Also frustrating, it seems to be impossible to determine what piece of the input date is focused (ex document and window .getSelection().toString() is empty).

How can I set the starting time for the time input widget?

I'm working on web app and I use this custom component based on a classic <input type="time">
<ui-input type="time" step="900" value.bind="nbH">
It's basically the same as a classic <input>, in the context of my question, it doesn't change anything
<input type="time" step="900" id="appt-time" name="appt-time" value="13:30">
The problem is that I'm using this component like a field indicating the number of hours (less than 24 hours) and not like an indicator of the time.
So I would like to change the default value when you click the clock icon. I would like to choose a a fixed value by myself because I don't want the default value to be the current time. Is it possible?
And then, I would like the step to be used also for the display of the hours and minutes list when you click the clock icon, not just with the top and bottom arrows of the keyboard. So instead of display each minutes (in the right column), in my case it would display 00, 15, 30, 45. Is it possible?
I didn't find what I searched in the doc so I wanted to know if I can do these things without creating a new whole component.
The kind of customization you desire is AFAIK not supported by the standard <input type="time">. Also note that what is considered 'standard' may differ between browsers and sometimes even browser versions.
A custom component is most likely the way to go, possibly even based on <input type="text"> so you won't have to deal with "time" behaviour getting in the way of your custom actions.

How to make iPad HTML5 date default to blank/empty when using next button

The iPad defaults to today when an input type="date" gets focus (due to next/previous buttons and I presume tab/shift-tab using bluetooth keyboard) e.g. test using http://jsbin.com/etovur/1 on an iPad.
Question: Is there a workaround that works on both the iPad and iPhone to make the date not default to today when just navigating through the field?
This is a UI problem when editing existing data, and using next/previous to navigate through the fields, because it changes a blank to today e.g. termination date field of an employee gets set to today, and the employee is sacked.
We only need a solution that works on iPad/iPhone, and beware that input type=date implementation between the two devices has significant differences. Desktop browsers don't matter because we use a non-native date control (precisely to avoid problems with variation in how date controls work and look, or whether they are provided). The issue happens on at least iPad with iOS5, and iPhone with iOS6.
Mostly working solution: see http://jsbin.com/etovur/5 - when the date input gets focus set the value to '' after a delay.
setTimeout(function() {
document.getElementById('adate').value = '';
}, 0);
The biggest problem is that this workaround makes it hard for the user to pick today (the user must scroll away from today and back again to pick today). Since this is an effect of the IMHO flawed over-simplified UI of the datepicker on iOS, I don't think there can be any viable solution to my original question.
Some possibility of timing bugs (next then quickly next on slow iPad?).

Force a numeric keyboard but allow punctuation: HTML5, mobile Safari

I'm building an HTML page to be viewed in mobile Safari [and other platforms]. The page lets the user specify several start and end times. They have to input at least two times, and possibly more depending on their situation.
I want the user to be able to input their times as numbers and punctuation using the numeric-SHIFT mode keyboard, i.e. the user will see fields like this:
And they'll get the numeric-SHIFT keyboard when they focus into the field:
Won't work:
<input type="time"> (and related datetime types) is not an option. The scrolly-wheel is unacceptable from an HCI perspective, particularly for repeated entries.
<input type="number"> does the right thing at first. It triggers the keyboard in numeric-SHIFT mode, i.e. the numeric & punctuation portions are visible by default. But when you exit the field, mobile Safari strips out punctuation (i.e. the colon). I tried turning off validation in the form using novalidate but that didn't work.
<input type="text" pattern="[0-9]*"> triggers the telephone keyboard with no way to enter the colon character.
I may just need a different RegExp in the PATTERN attribute, but each one I've tried triggers the normal alpha keyboard, and the user has to hit a key to get to the numeric-SHIFT keypad.
Can anyone tell me how to force the keyboard into numeric-SHIFT display without triggering harsh validation rules on the user's input?
Take a look at jQuery Mobile DateBox. here. Its possible you might want to rethink text input here. Maybe you want to go with a picker. Sencha Touch also has a DatePicker. I wrote an extension that implements a timepicker object. I'll throw it up on GitHub if you need me to.

How can I avoid browser prepopulating fields in my registration form?

autocomplete="off" is not what I am after. Basically, on my registration form there are fields "phone" and "password" placed one above the other. (see screenshot)
The "phone" field gets, annoyingly, prepopulated with a username, as I guess what the browser is doing - the browser finds a field of type password and assumes the text input field just before it is a username field. The effect is this:
Why I am not interested in the non-standard autocomplete attribute for the phone field, is that I do want user to be able to fill this form as easily as possible and if they have previously entered their phone number on other sites (into fields called "phone") they could benefit from this showing up as they start typing into the field. That's why I don't want to turn autocomplete off altogether.
I was thinking more in the direction of reorganizing the fields somehow to avoid this behaviour. Or some way of telling the browser that the field above the password field has nothing to do with it, or that the password field is not used for authentication purposes. Somehow mark it as that. Or inject some invisible element inbetween these two fields?
Any ideas?
Markup used:
<input id="phone" name="phone" type="text" value="" maxlength="30">
<input id="newPassword" name="newPassword" type="password" value="" maxlength="20">
I am getting this behaviour on Chrome, FF, (not sure about IE, got an archaic version of that on my machine, don't even want to start worrying about IE yet.)
Most password managers will search the first password field, and the closest text field before it.
So all you have to do is add invisible text and password fields (display:none) above "new password".
Firefox tries to interpret 3 password fields as a "change password" action, so if you don't want that you should be safe adding yet another invisible password field.
I had a similar issue with the set password field. Try
<input type="password" autocomplete="new-password">
From MDN input documentation:
autocomplete
This attribute indicates whether the value of the control can be automatically completed by the browser.
Possible values are:
....new-password: A new password (e.g. when creating an account or changing a password)
For the phone number issue, I set this and it stopped autocompleting the username there.
<input type="tel">
A home number cannot be 30 characters, this is probably why the browser is assuming it could be a username or login email due to the size. Change it to something real and see what happens.
Also, consider having 3 field for phone number, area code, prefix, suffix. Once a certain number of digits are filled, you can auto focus using JavaScript the next phone segment field so it's easier for user.
Have you also tried changing positions of fields? What's happened?
Also, just to make sure, you can turn off auto complete on a particular item during registration without worrying that it will be off during login (cuz it won't) unless you turned it off for the login fields as well, and of course you have no need to.
Also, delete your unused saved form auto complete stuff, could just be a local issue with your version, you may have entered a bad value one day in one of the browsers, and then you installed the other browser (chrome or FF), and then the newly installed browser copied the rules exactly as they were from your original browser.... So, you end up thinking it's a global issue with your form, simply because of one bad entry and because your second installed browser copied and replicated the bad entry rule from your first browser, making it look like a real, universal problem to you, get me? So try the browsers InPrivate modes, or try the browsers from a different installation or a different computer, or from a virtualpc instance you may have.
Otherwise, export all your setting from your browsers and uninstall both browsers, then reinstall from scratch FF and chrome, then test your webpage, then feel free to import your exported settings back.
Also, test on IE even if it is for the insight it may give you, know what I mean?
Hope this helps, let me know how you get on, and if you have any other questions.
UPDATE:
Given the method you've chosen, what you should be able to do is, when rendering the phone field, add a value=" " attribute into the input tag, instead of using JavaScript. This should prevent the pre-filling from occuring without needing to use javascript. Now, if you want to go one step further, you can do this:
During the OnLoad Event of when page loads, check the phone field using JavaScript, and if the value equals one space (" ") then overwrite it with an empty string using JavaScript once onLoad is triggered. Or, if the browser is still prefilling (i doubt it will but if it is) you can delay this check by a few hundred milliseconds and run the javascript a few hundred milliseconds after the page has loaded, or tie it to all or some of the input fields onFocus events, so as soon as any of the fields gain focus, you do the "does phone.value equals one space character (" ") and if it does, overwrite it with and empty string, i'm even more certain the browser isn't going to jump in and hijack that field in this situation. Although, as mentioned, even if you do this onLoad, i doubt the browser will hijack your field, as the pages/javascript onload occurs AFTER the browsers internal onLoad (DocumentComplete) event occurs, and worst case scenario, you can do the few hundred millisecond lag or onFocus method, but i doubt you will need these.
Let me know how it goes.
I tried disabling the input fields type=text& type=password after loading of the DOM then enabled all the disabled fields after certain milliseconds lets say 100. It seems to be working for me.
Try :
$(document).ready(function()
{
$("input[type=text],input[type=password]").prop('disabled','disabled');
$("body").delay(10,function(){
$("input[type=text],input[type=password]").prop('disabled','');
});
});