In Chrome undo does not work properly for input element after contents changed programmatically - google-chrome

In Chrome, I noticed that undo does not work properly for input element after the contents of the element has been changed programmatically. Although I get different behaviours for different browsers, they're not as bad as Chrome.
FF20 good
IE9 some support (undo stack cleared when input loses focus)
Safari5 some support (undo stack cleared when input loses focus)
Chrome26 unreliable
For example, a script that trims spaces (see also jsfiddle below)
type some spaces before "hello!",
click outside the input element
click on the input element and press Ctrl-Z
now the text is gone (in Chome)
jsfiddle here
<input type="text" id="input1" value="hello!">
document.getElementById("input1").addEventListener('blur', function(evt){elementLosesFocus(evt, this);}, false);
function elementLosesFocus(evt, caller)
{
caller.value = caller.value.trim();
}
I think the best thing I can hope for is a method to somehow clear the undo history of the input when it loses focus (as is the case with IE and Safari).

Chrome doesn't store the field's states, but rather a diff or set of deltas for each undo/redo. It takes less memory, but causes the bug you're dealing with.
You can effectively simulate the user pasting a value into the field by using document.execCommand("insertText", false, "text to insert");.
For your particular case:
First, save the field's value to a variable. var temp = caller.value;
Next, clear the field's value or set its selectionStart to 0 and selectionEnd to the field's length. This way a simulated paste replaces the field's contents.
Next, make sure the field has the focus. caller.focus();
Finally, simulate the user pasting in the modified value. document.execCommand("insertText", false, temp.trim());
I found this solution in another SO question, https://stackoverflow.com/a/10345596/1021426

Related

How to programmatically show the left most content of the HTML input element when the text is longer than the input itself in React

I have an input element which it's value is 'abcdefghijklmnopqrstuvwxyz'
I used ref to highlight the content of 'n' to 'z'
inputRef.current.setSelectionRange(18, 26);
which result into this:
How can I programmatically set the input to this instead?
Additional insight:
If I switch to another tab on the browser and go back to the tab containing this input, it will result in what I want, but I do not know how to make it work with code.
You can use the Element.scrollLeft attribute with decent browser support now, here's a Codesandbox: https://codesandbox.io/s/flamboyant-panini-02gr7l?file=/src/App.js
I've used timeouts to setup the scenario but the key part is here, and it requires a timeout since it needs to fire after the setSelectionRange call.
setTimeout(() => (ref.current.scrollLeft = 0), 100);
As with timeouts in general, the time required is a bit flaky.

Decimal value in Polymer core-range

How to input decimal value in core-range, as in given demo?
With 'step' attribute added:
<core-range step="0.5" min="0" max="200" value="{{value}}" ratio="{{ratio}}"></core-range>
I can paste decimal(e.g. 5.5) in the input field but cannot type it?!
That's pretty interesting. I think it's a bug in the core-range element itself (https://github.com/Polymer/core-range/blob/master/core-range.html). As the input gets validated "5." gets overwritten by the number 5 and set as value. Since it is reflected in the input field itself, the input changes to 5. When you paste it in as a whole, the "5.5" stays and is reflected in the input field. That's why it works when you paste it. I don't think there's a work around other than fixing the bug.
Issue opened:
https://github.com/Polymer/core-range/issues/2

iOS Safari HTML form next/previous buttons - how do they work?

Disclaimer: I am using JQuery Mobile.
I have a bunch of pages with different forms on, but some of them seem to exhibit different behaviour when pressing the next/previous buttons.
All forms are set up with tab index.
Form 1 works perfectly, except it skips the JQuery Mobile flip switches and radio buttons, which isn't really a problem as they are a bit different.
Form 2, the element with tabindex="0" has focus set to it using $("#myElement").focus(); and then the next button is disabled, and pressing the previous button goes to the bottom of the form, i.e. the next/prev order seems to be 1, 2, 0.
Form 3 seems to be completely erratic, this time going downwards in order but some fields seem to be setting the focus to the label first, then pressing next again causes the input field to be selected.
Form 4 works fine, apart from the last select field seems to be ignored. Then the tabindex jumps to some anchor elements on the page before continuing to the flip switches.
Form 5 has the same behaviour as Form 4, again the last select field in the form is ignored.
I will continue to investigate this, and produce a fiddle, but has anyone experienced these kind of issues or has some insight into how they should work?
OK all these are my errors but it might help someone, so here goes.
The next/previous order does seem to be directly related to the tabindex attribute, with no strings attached.
However to my error, tabindex starts at 1 not 0. http://www.w3schools.com/tags/att_global_tabindex.asp. So for Form 2, it started at 1, then 2, then 0.
I was using knockoutjs to bind the tabindex attribute to the $index() of an observableArray item that represented each field and field value, which made the error harder to spot. So I had to change it to $index() + 1.
For the radio buttons, the index was being taken from the collection of options, not the parent, so I had to use $parentContext.index() + 1 for those (see here: https://stackoverflow.com/a/11013401/1061602).
Attempting the same approach for flip switches doesn't seem to do anything.
The completely erratic form was because there was another form still existing on the DOM that had tabindex attributes set to a similar set of values, so it is tabbing between the two forms in turn. The easiest solution for me was to hide the existing form, see here: https://stackoverflow.com/a/5494043/1061602.
The commonality between Form 4 and Form 5 was also that they had the same tabindex (6) however this was a red herring. Still investigating why the last select field is skipped in Chrome - however on iOS Safari it works as expected, so problems solved!!
At least for Firefox/Chrome, you can use mozactionhint:
<input name="foo" tabindex="1" mozactionhint="Next"> // will go to next: "bar"
<input name="bar" tabindex="2" mozactionhint="Next"> // will submit the form
<input type="submit" tabindex="3">Submit</input>

Resulting request for input type="image" forms

Web developers can use <input type="image" name="name"> to present their users a graphical submit button. The w3 standard on html forms regarding input controls states that
When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.
Now, I know that Firefox will generate a request that contains name itself, whereas Internet Explorer does not. my question, is Firefox providing additional functionality on top of the standard, does Internet Explorer not implement the full standard correctly (happened in the past …) or is the standard simply unclear regarding this aspect?
edit
It looks like Firefox creates a weird request (or it is parsed in a strange way by PHP). if the input name is an array (i.e. name[1]) the resulting $_POST variable will contain: ["name"] => array(1) { [1]=> string(2) "57" }. so the .x component is munged and the .y component is turned into the only value …
edit 2
Upon further investigation it looks like even Firefox does not send the control's name when it's of type image, even with the value attribute set …
addendum
It seems like that what I really want to know is how I can make use of <input type="image" name="el[]" /> elements when the name is an array, without messing up the POST request.

What is <input type="image" /> typically used for?

I clicked on it and the form is submited, along with a query string appended like x=1&y=2 to the url targetted by the form's action.
Why?
The x and y values are the co-ordinates of the mouse pointer relative to the element when clicked.
From the HTML 4.02 specification:
When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.
It behaves like a mini imagemap. This is by design.
IMAGE is a TYPE attribute value to the INPUT element for FORMs. It specifies an image that can be clicked upon to pass information to the processing script. In implementation, this form TYPE acts much like the INPUT TYPE=SUBMIT field, but unlike the SUBMIT field, the coordinates of the image that were activated are sent back to the server in addition to the rest of the form data.
from eskimo.com
IE and Firefox will both create different variables when submitting from an image submit button. My advice is not to rely on any of them being present in your form processing. If you must (to determine which of multiple buttons was pressed) you will need to check for multiple variables.
I'll give you three guesses which browser causes the problem and the first two don't count. If you have an image button
<input type="image" name="restore" value="Restore" src="...">
when the user clicks, Mozilla will return the values
restore = Restore
restore_x = number of pixels from top of image
restore_y = number of pixels from left edge of image
IE, however, will not return the restore=Restore Template key/value. So you can get caught if you develop in one browser and then test in IE, because
isset($_POST['restore'])
will always return false in IE, but will work as expected in Mozilla (and probably Opera but I don't know off the top of my head).
From a 2004 webmasterworld.com forum post I just googled
Those are the coordinates that you clicked on an image, a property of the "image" type of input control. You can ignore those if you don't need them.