selectOnClick on TextItems with markForRedraw always selects text

[SimonF]

Hi,
we are using a textitem with a change event and the selectOnClick-option set to true. In the change-function we have to call the markForRedraw because the form could be changed by the change-method. In the example i have simplified the problem.

If you click in the textitem it isn't possible to write a sentence or a word because the selectOnClick is always firing. I think this is a false behavior and should not fire again.

We currently using SmartClient_v100p_2014-10-21_Pro and it happens in all browsers.

isc.DynamicForm.create({
	"ID" : "theForm",
	"readOnlyDisplay" : "static",
	"fields" :
	[{
			"ID" : "textitem",
			"changed" : function (p1, p2, p3){ 				
					theForm.markForRedraw();
			},
			"name" : "textitem",
			"title" : "name",
			"type" : "text",
			"selectOnFocus" : false,
			"width" : 300,
			"selectOnClick" : true
		}
	],
	"values" : {
		"textitem" : "start to type"
	}
})

[Isomorphic]

We've made a change to address this issue. Please try the next nightly build dated Oct 28 or above.

Regards
Isomorphic Software

[SimonF]

thanks it is fixed with the latest nightly Oct 28

[SimonF]

There seems to be another problem with the currently version SmartClient_v100p_2014-10-28_Pro.

If you enter text at the end of the textbox it works fine. If you put the cursor in front of the text and start to type, after the first letter the cursor jumps to the end

[Isomorphic]

Nice use of an animated gif to demonstrate this!
We'll take a look and let you know what we find.

As an aside - are you sure you really need to redraw in response to every change event, and have changeOnKeypress set to true? While redrawing during typing should be supported and we'll try to resolve this second bug, it seems a slightly inefficient way of handle this. Would it be better to have logic in your app which actually detects whether a redraw is truly necessary on change and only redraws if so?

Regards
Isomorphic Software

[Isomorphic]

We've made a change which we believe addresses this issue. Please try the next nightly build dated Oct 31 or above, and let us know if you continue to see issues in this area.

Thanks
Isomorphic Software

[SimonF]

thanks,
we tested in Version SmartClient_v100p_2014-11-02_Pro and there it seems to be fixed.

I'm not 100% sure if we need the redraw at this point, but it's possible that we need do change elements through changes typed in the TextItem. I know it's not the nicest way to mark the parent component as markforRedraw, but we also run into problems switching different TextItems to canEdit:false. I don't know in what, situation this happened, so i can't give you any example.

Thanks for the fix
Simon

[SimonF]

hi,
i have some good and some bad news.

The good news is, that the fix works in all modern browsers (tested in Firefox, Chrome).
The bad news is, that in "browsers" like Internet Explorer 9 the issue still exists. But now the bug only occurs if you are fast-typing. I've tried to write fast (including some typos) but i think you get the problem.


This happens also in IE10 and IE11, but in IE9 it's faster reproducable.

[Isomorphic]

We do see the effect and are working tirelessly to figure out how best to resolve it!

Isomorphic Software

[Isomorphic]

We've made a change to fix this issue.
Please try the next nightly build, dated Nov 5 or above.

Regards
Isomorphic Software

[SimonF]

thanks for fixing this issue, this seems to fix it.

Sorry for reopening this thread.
Sadly since the fix we have multiple reports about an js-error, which ma be collerated with this fix.
We have a callback for js-errors in the browser, so every js-error is sent back to us through our backend.

Because of this we have recognized a increase of a specific error in the js. We don't know how we can specific reproduce this, but this may correlate with the fix of this issue.

We have rolled out Version v10.0p_2014-11-12

The error occurs on IE9 (User-agents Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) )

Most of our clients use the german IE9, but i'm sure this is not dependent on the language
ISC_Forms.js: Für die Eigenschaft "length" kann kein Wert abgerufen werden: Das Objekt ist Null oder undefiniert ( 1020)

it translated to:
Uncaught TypeError: Cannot read property 'length' of undefined

the line 1019 and 1020 in the file is this part

if(isc.Browser.isIE){var _1=this.$17p();if(_1)return _1.text}else if(isc.Browser.isMoz||isc.Browser.isSafari){var _2=this.getElement();if(_2!=null){return _2.value.substring(_2.selectionStart,_2.selectionEnd)}}},isc.A.$100a=function isc_FormItem__IESelectionStuck(){if(!isc.Browser.isIE)return false;if(isc.Browser.version>9)return false;try{var _1=document.selection?document.selection.typeDetail:null}catch(e){this.logDebug("Internet explorer native 'stuck focus' state detected");return true}
return false},isc.A.$17p=function isc_FormItem__getIESelectionRange(){if(!isc.Browser.isIE)return;if(isc.isA.TextAreaItem(this)&&!this.supportsSelectionRange)return null;var _1=this.getDocument().selection,_2=(_1!=null?_1.createRange():null);if(_2!=null&&_2.parentElement().id==this.getDataElementId())return _2;return null},isc.A.rememberSelection=function isc_FormItem_rememberSelection(_1){if(!this.isDrawn()||!this.getClass().isMethodSupported(this.$146r))return;if(!isc.isA.TextItem(this)&&!isc.isA.TextAreaItem(this))return;var _2=this.getElementValue();if(_2==isc.emptyString)return;this.$17q=_2;var _3=this.getSelectionRange(_1);if(_3){this.$17r=_3[0];this.$17s=_3[1]}},isc.A.resetToLastSelection=function isc_FormItem_resetToLastSelection(_1){if(!this.isDrawn()||this.$17r==null)return;var _2,_3=this.getElementValue(),_4=this.$17q;if(!_1)_2=(_3==_4);else{_2=true;if(this.$17r==0&&this.$17s==_4.length){this.$17s=_3.length}else{if(_3.toLowerCase()!=_4.toLowerCase()){this.$17r=this.$17s=_3.length}}}

in the last line there are 3 usages of .length. One of these seems to reference a null object in some cases with IE9.

Is there a fix possible to catch this js-error?

[Isomorphic]

We can add a null check here to avoid this problem.
Since we've never seen it on our end and are not entirely clear on how the app got into the bad state we can't guarantee there isn't a deeper problem we're papering over here. If you continue to see problems with the next nightly build (Nov 26 and above), please let us know and we can take another look. However we probably will need a way to reproduce the problem.

Also as an aside - the exact line number / error message was useful for pinpointing where the error occurred, but not why. If you could also capture a stack trace on errors, an examination of the code flow prior to the crash can often hint at the underlying cause.

Regards
Isomorphic Software

[SimonF]

thanks for the repsonse. Like i said, we can't also reproduce it, thats what's really bad at this. I know that fixing bugs, are easier if you know how to reproduce in detail.
If the js-error persists in future releases i'll try to get the stack to get a detailed look why the error is thrown.