HTML5 gives us some new input elements to play with, such as <input type=number>. This renders (in Chrome) as a textbox with two cycle buttons inside the textbox, for incrementing and decrementing the numeric value inside the box.
For a personal hobby project, I'm using this control. However, I'm stuck with one issue:
Is there a way to detect the value being changed using a javascript event? I had expected the onChange event to fire, but no such luck. Also, onClick only triggers when the textbox content is clicked, not when the cycle buttons are clicked.
Any ideas? (apart from: hey, it's HTML5 Forms, don't expect anything to work yet!)
Edit: As mikerobi points out below, the onChange event does fire as soon as the element loses focus. Still not quite what I'm looking for, so other comments and suggestions are welcome!
Result of the bugreport: Won't Fix, because the input event is fired when those buttons are pressed. It's part of the HTML5 spec. So problem solved, thanks to mikerobi's sugestion to file the report.
The onChange event gets fired when when the box loses focus, but you probably already know that.
The HTML5 specifies that a number input should be a text box or spinner control, but the spec does not appear to have any guidelines for how a spinner should look or behave, leaving those decisions up to the browser vendors.
It appears that in the Mac Safari, the spin buttons do respond to click events, you might want to file a Chrome bug report, I suspect it was just an oversight.
$.click() works fine. If you click and hold, it doesn't until you release.
Related
I am working on a custom application for the iPad that runs as a homescreen app, but is made in all CSS/HTML/Javascript. (not using the SDK here)
I have run into an issue with a calculator I have built into my page not hiding the keyboard. No matter what I do, the keyboard stays up. I have searched this extensively and tried everything I can think of, but the keyboard stays up no matter what I do.
Explanation of what I have tried to hide the keyboard:
I have tried to blur all input fields to remove focus. I have tried setting focus onto non-text field items.
There were several threads on Stackoverflow from earlier this year/last year that suggested both of those options, but they do not appear to be working anymore.
To test further, I put a blank a href="#" on an img that was above the calculator, so that I could set focus on a non-entry and see if that would auto-minimize the keyboard. When I tap that item above the keyboard the focus changes and I am no longer in input mode, but the keyboard stays up.
Did Apple break this functionality with the latest update? If so, is there a work around?
Here is some example code that doesn't work:
$('input').blur(function(e) {
// Keyboard disappeared
window.scrollTo(0, 1);
});
That code successfully removes focus from the inputs, but the keyboard stays up. I have also attempted the inverse of that by just .focus ing on a non-text element. And additionally, as stated previously, I have straight-up just added a non-text element on the page and that still doesn't hide the keyboard.
Thanks so much for any help, and feel free to link/abuse me if I have mistakenly reposted. :)
you should be able to blur it just by using something like this
$('input').blur();
you should put this inside the function/procedure that happens when you want it to disappear, unless your looking to disable it completely?
document.activeElement.blur() inside a try catch block works for me. (Possibly you also need a setTimeout? I didn't need a timeout, and it is important to avoid timeouts wherever possible because they can easily cause nasty heisen-bugs!)
Also double check that you are not calling focus() somewhere within a mousedown or click event (which causes the keyboard to show). You can use a console.log(document.activeElement.tagName); or similar to help find what has current focus.
However if you don't find a solution then I am very interested in seeing how you get the keyboard to stay up... I have a use for that :-)
I need to reliably detect the state change of radio buttons/checkboxes on my page in order to watch if the form was modified or not. Now, this is a completely separate script, I cannot modify anything that controls the form.
Right now, I can see only two ways of doing this:
onchange event handler, which helps with textboxes, textareas and selects, but is not fired for checkboxes/radiobuttons
onclick event handler, which is not reliable, because users often use hotkeys to change the values of these elements.
What am I missing here? Is there a way to reliably detect that checkbox was checked/unchecked?
UPDATE: As you guys pointed out, change event is really fired on checkboxes/radiobuttons, despite the fact that w3schools says it is only for text inputs
However, my problem turned out to be that the values of checkboxes/radiobuttons are set via setAttribute in scripts and in that case the event is not fired.
Is there anything I can do in this case?
See: http://www.quirksmode.org/dom/events/change.html.
It says that all major browsers support change event but the IE's implementation is buggy.
IE fires the event when the checkbox or radio is blurred, and not when it is activated. This is a serious bug that requires the user to take another action and prevents a consistent cross-browser interface based on the change event on checkboxes and radios.
I think you can overcome IE's bug with this trick. blur() elements when they focued! (Use something like $('input[type=radio]').focus(function(){$(this).blur();}); in jQuery or use pure javascript)
Ok, after some digging, here is what I found out. Note, this is applicable to Firefox, and, probably to Firefox only. Since in this case I was dealing with internal application, this was enough for me.
So, basically, in order to reliably detect changes in checkbox/radiobutton state in Firefox, you need to do two things:
Set up custom Firefox's event handlers CheckboxStateChange and RadioStateChange for checkbox and radiobutton respectively. These events will be fired when the user changes the inputs or when it is modified via script, using setAttribute, however, these events are not fired, when the state is changed in the script, using checked or selected properties of these elements, this is why we need ...
Watch the changes of the checked property using Object.watch
Standard onchange event is no good, since it only fired when user changes the value directly.
Damn, this thing is broken...
If people get interested, I'll post some code.
I have a page with an input box, and a function that processes the value of this input box and produces piece of text. I want this text to always be up to date in relation to the contents of the input box, so I've attached a couple of event handlers to it with jQuery to catch any changes:
$('#input').bind('keyup cut paste', function(){...});
This works well in most cases. Whenever the user modifies the contents using the keyboard in any way, or right-clicks to use the cut or paste functions, the text is updated immediately. However, there are two events I still haven't figured out how catch, if it's even possible to do so:
When the user selects a of text and drags it do a different position in the input box
When the user uses the Delete action in the right-click context menu
Both of these can of course be detected by binding the change event, but the problem with that approach is that it doesn't fire until the input box loses focus. The whole point of these bindings is to have the text update in real-time as the value of the input box changes, so change is no good.
English is my second language so I could simply be bad at wording my Google searches, but so far they've turned up nothing. I haven't found any solutions to this after digging through a couple of related Stack Overflow pages either, so I'm asking here. Is there an event binding for this that I don't know of? If not, is there a different approach I could take? Or is this simply not possible with plain JavaScript?
In non-IE browsers, you can handle the input event.
In IE, you can handle the propertychange event.
Demo (works in all browsers)
It's possible this SO question (and related jsfiddle) might answer your question.
(On the linked jsfiddle, put text in the top box to test)
In other words, bind to mouseup and mousedown, etc.
If you can't find a combination of events that cover all cases, you may want to use setInterval(function() {... }, period). You could play around with the period to see how well this works.
i have made auto grow textarea.it's working fine but when copying and pasting using right click it's not working properly.if i use onchange event in this situation it won't work either because to fire this event we need press enter or tab. please help me to solve this problem
How about additionally listening to the onpaste event? It's not part of the standard, but works in most major browsers.
You could you a setTimeout to check the character length of the textarea and change it accordingly.. doesn't feel very nice though.
Alternatively you could detect that the right mouse button was clicked using the which or button variables. see here
When it comes to navigating through an HTML form by hitting the TAB key, Internet Explorer 7 treats an INPUT element with TYPE=FILE as two controls (see MSDN for details). The first time you hit TAB it focusses on the text field, and the second time it focuesses on the Browse button. This is invisible to JavaScript.
The problem is I want to use Ajax Upload or something similar to allow the user to click what looks like a button and see the File chooser appear. This works by placing an invisible file-input element under the mouse. I have managed to change the script to allow you to TAB to the hidden file-input element and for this to trigger a CSS change so the fake button looks like it has focus, the upshot being that, on browsers other than IE7, it looks to the user as if you can tab to the button and activate it as you would expect.
This cannot work on IE7 because the first TAB takes it to the invisible text field; pressing SPACE adds a space to the invisible file name instead of activating the file picker. I have tried adding an event handler for keypress that calls the click event, but when I do this the change event I am depending on seems not to be fired.
I am beginning to think the only accessible solution on IE7 (and, I assume, IE8) will be to replace the whole dialogue with a two part form -- the first part with a (visible) file-input element and Upload button, the second part with all the other form items. This is unfortunate because (a) IE7 get a less slick user experience, and (b) I have to add all sorts of extra server-side code to allow the form to be submitted in two parts.
So I would be interested to know if anyone has a way to make IE7's file-input element behave like a single control, or, alternatively, to allow JavaScript to access both controls of the element (something the DOM was not designed for!).
This a bit complicated to do but here's how:
Create a new button to use as your "fake" input control (you have this as the visible element). This element needs to be a button or a link for it to be able to get tab focus (I suggest button so that it works better on Safari).
Remove the file input from the tabbing order by setting it's .tabIndex to -1. It should now be hidden from sight and tabbing order.
Assign events to the file input so that on activity then the focus is moved back to the fake button, values are copied from it, and so forth.
Assign a click event to the fake button that calls .click on the file input element. This will only work for IE. It will also very likely break in a future release.
For mozilla style browsers you can move the focus from the fake button to the file input on keydown, the keypress event will the occur on the file control and you can then move the focus back to fake button on change. This should also give you del/backspace functionality (clear field).
Clearing the field in IE can only be done by rebuilding a new file input control.
As should be obvious from my other answer, I have managed to build this widget with full keyboard accessibility.
My sincere advice is to drop this pursuit. It is a maintenance nightmare. You are exploiting security holes in the browser to make this work and it is only a matter of time before vendors close something that you rely on.
You could also check out swfupload, as it may provide what you're going for and more.