iPad Safari - selection range on click isn't working

[ESherbakova]

1. SmartClient_SC_SNAPSHOT-2012-03-08_v82p

2. iPad Safari

Browser-side problem
Sample case: when we click on the masked field (e.g. phone # field below) we want to reset the selection to a particular position ({3, 3} in script below)
However, in iPad Safari browser, reposition on click doesn't work



isc.DynamicForm.create({
width: 400,
fields: [
{ name: "firstName", title: "First name", type: "text",
mask: ">?<??????????????", hint: "&gt;?&lt;??????????????"},
{ name: "lastName", title: "Last name", type: "text",
mask: ">?<??????????????", hint: "&gt;?&lt;??????????????"},
{ name: "state", title: "State", type: "text",
mask: ">LL", hint: "&gt;LL"},
{ name: "phoneNo", title: "Phone no", type: "text",
mask: "###-###-####", hint: "###-###-####", hintInField: true,
click: function(form,item){
item.setSelectionRange(3, 3);
}
}
]
});


I have noticed that in Firefox and desktop Safari re-positioning is not working all the time either. If you play around for awhile you can see that occasionally the position remains/resets to the end of the field, not to the indicated {3, 3} segment

[Isomorphic]

Just a quick update to let you know we are reproducing this issue on the iPad.
One of our developers is working on it.

However more fundamentally this approach is a little unwieldy for a couple of reasons.
Firstly, when a mask is specified, under the covers the framework is both updating the form item value (to display the appropriate spacer characters) and managing the position of the cursor within the item. This is what allows a mask like "##-##" to have the user enter four digits without entering the "-" character and things "just work". If application code is calling 'setSelectionRange' directly in response to user events it's quite possible that you'll end up interfering with this built-in behavior - essentially its hard for us to guarantee the results of doing this in conjunction with having a mask specified.
Secondly you're reacting to a click event, but focus can also be put into the field via a tab keypress etc., programmatic focus when a "picker" is dismissed, etc. Obviously it depends on your use case but you should consider carefully exactly what behavior you're after.

Let us know what you're trying to achieve in terms of user-experience and we may be able to suggest a better approach.

[ESherbakova]

Thank you.

We are accounting for the "focus" event; "click" was used to demonstrate a simple test case.

We use custom logic to transform input in masked fields. Once the input is transformed the cursor position must be reset to a meaningful position. For instance, our custom mask transforms integer entry into decimal and cursor position must be reset once decimal point is inserted.
The most trivial example is when a user clicks on an empty phone field ###-###-####. No matter where the user clicks on the field the cursor must go to the end of the user entered value, i.e. if field is empty " - - ", the cursor must go to the very beginning of the field. This currently fails in iPad.

[Isomorphic]

Ok - we now understand what you're trying to achieve (makes sense). However you should be aware that simultaneously using input transform in conjunction with masking would be expected to yield unpredictable results - as indicated before the "mask" logic does its own input transform and caret position management so it's very likely that this would interfere with your custom logic and vice versa (frankly it's quite surprising that this is working for you across desktop browsers).
We'd encourage you to either have entirely custom input transform logic and not use 'mask', or just use the mask feature rather than trying to combine the two.

Also note, this aspect of the discussion is not responsible for the iPad issue which appears to be essentially failing to fire the click handler logic at all - we're still investigating this and will let you know when we have a fix.

[Isomorphic]

We've made a change to the TextItem code which should cause it to fire click events properly. This will show up in the next nightly build in both 3.0p and 3.1d branches.

[ESherbakova]

We are using branch 82p and the lastest build SmartClient_v82p_2012-03-30 does not contain the fix.


I did not express myself correctly while trying to explain our case. We are not using mask + custom transform input simultaneously, we are using either or depending on a situation. We do, however, set cursor manually in both cases

1. Masked field - Phone number
In the phone number field we need to always set the cursor to the end of the user entered value. (I gave an example in one of the comments above)

2. Transform Input - integer to decimal
When we transform integer into decimal by adding decimal point we need to reset cursor to account for the new character.

[Isomorphic]

Please double-check your installation and make sure you're not still using the older version.

[ESherbakova]

Yes, we double-checked and tried on 2 different servers.
The behavior is not fixed, we tested in both: iPad and Galaxy
Can it be because we're using branch 82p, not 3.0p (what is 3.0p?)

[Isomorphic]

What are you reporting as not fixed:

1. click events not always firing for a masked textItem

2. setSelectionRange() not behaving as expected *in the standalone test case you showed*

3. the overall interaction in your app still not working

[ESherbakova]

What fails is
2. setSelectionRange() not behaving as expected *in the standalone test case you showed*

[Isomorphic]

OK, we'll take a second look at this and see if we can reproduce the problem again - you mentioned it's intermittent before - is it perhaps occurring far less often now (like as rarely as 1 in 20?).

[Isomorphic]

There was a bug in iPad whereby the click handler wouldn't fire at all for text items -- that is now resolved. So we're dealing with just selection range issues at this point.

--

When you have a mask defined on a field, the intended default behavior causes the text insertion cursor to be positioned after the last user-entered value when the field gets focus.

To take the phone number example - say you have a mask of "###-###-####" - initially the field will presumably be empty.
When the user puts focus into the field, our logic forces the cursor to the first position (Imagine "|" indicates the cursor position):

  |___-___-____
  ^ cursor position

If you have a partially filled value (so tweak the above example to have defaultValue set to "503", say), our logic positions the cursor after this partial value - so you should see this:

  503-|___-___
      ^ cursor position

This is the default built-in behavior, and sounds like what you are after. From testing with the initial test code you posted above, if you get rid of the click handler on the "phoneNo" item altogether, this should be what you are seeing. It is for us, with or without a default value of "503".
If this doesn't match what you're seeing, please let us know - this indicates a bug.
If this is the case please be sure to state anything that might help us reproduce it on our end -- is it intermittent? How frequently does it occur? Is a page reload required to cause it? Also - are you running the attached test code as a standalone file or are you using the feature explorer to run the code?

Adding your own logic to the click handler to explicitly change the selection range is not really supported in conjunction with the mask feature - essentially the two bits of logic will fight with each other.
It's not clear how we could resolve this. If we entirely disabled the logic to set caret position when mask is enabled within the framework it would make the mask feature basically useless - to support the feature we have to both transform input and ensure the caret is in the right place. We therefore have no plans to change this. Moreover it sounds like the default behavior matches the behavior your trying to achieve via explicit coding so it's not clear that anything needs to actually happen here.
If you think that the built in behavior doesn't match your use case let us know. That may indicate we need to expand upon the default behavior.

We haven't touched on the case where you have an explicit transform in place. Are you also seeing strange behavior there? If can you show us a simple test case?

A couple of side notes:
- The example code has "hintInField" set to true. This is incorrect if you want the hint to show up in the field -- the property should be "showHintInField". We're aware the wrong property is shown in the inline examples and this will be resolved in the future.
- You asked about the difference between 8.2p and 3.0p. 3.0p is a SmartGWT build version based off the 8.2p SmartClient javascript code base. 3.0p doesn't apply to you since you're running SmartClient directly and not using SmartGWT -- we accidentally mentioned the version number for the wrong product in earlier comments.