JS Error in IE11 with IE9 compatibility mode

[martintaal]

Hi, we have a particular window that should load in IE9 compatibility mode, and it seems that by a corner case that I have not been able to reproduce with "plain" sources, a JS error is raised while trying to render the form.

I am with 10.0d and the problem is in FormItem.js here:

            if (this._IESelectionStuck()) {
                document.selection.clear();

The problem is that looking at the _IESelectionStuck function

    _IESelectionStuck : function () {
        if (!isc.Browser.isIE) return false;
        try {
            var typeDetail = document.selection ? document.selection.typeDetail : null;
        } catch (e) {
            this.logDebug("Internet explorer native 'stuck focus' state detected");
            return true;
        }
        return false;
    },

if there is a problem trying to identify "document.selection", the code goes through the catch, that returns "true", so later the "this._IESelectionStuck()" condition is "true", and then the "document.selection" fails, as it's logic.

I don't understand very well the purpose of this check, but changing the code by setting it as just as

            if (this._IESelectionStuck() && document.selection) {
                document.selection.clear();

fixes the problem.

I would appreciate if you could include it in your sources.

Thank you very much

[Isomorphic]

Sorry, while this seems like a harmless null check, it implies that you found a situation where our workarounds for IE's bugs are not fully effective, so we don't want to mask that with a null check that would basically skip the workaround in this corner case.

You can either:
1. See if you can reproduce the problem so we can put a correct fix into the framework

2. Try to maintain a local change, but revert it before reporting any future issues - we wouldn't recommend this course of action

[martintaal]

Yes, we agree that option 2 is not an option, and, at this moment, option 1 I don't think it be neither, since prepare a "simple" example to share with you where the issue can be reproduced will take us many man days. I can provide an instance where it happens, but I don't think this will be enough for you, or it could be?

Anyway, there is a thing that I don't understand. At the end, with this:

        try {
            var typeDetail = document.selection ? document.selection.typeDetail : null;
        } catch (e) {
            this.logDebug("Internet explorer native 'stuck focus' state detected");
            return true;
        }

you are trying to determine if "document.selection.typeDetail" exists or not, but you are assuming that "document.selection" always exists, otherwise you won't do this:

if (this._IESelectionStuck()) {
  document.selection.clear();

because with this you are assuming that "document.selection" already exists, otherwise my JS error will be shown.

Said that, adding the proposed check does not mean mask your IE workaround, in fact, is a way of improving it (at least in this scenario), since you will be able to do the finally needed "document.selection.clear()" when you really will be able to do it.

[Isomorphic]

We need a way to reproduce the problem.

Your analysis isn't correct. We are checking for IE throwing an exception when document.selection *does* exist, but certain properties are accessed.

[aliska]

Sample code

Hi,

I am able to reproduce it with this sample:

	final TextItem tmpItem1 = new TextItem("T1");
	tmpItem1.setValue("test1");
	final TextItem tmpItem2 = new TextItem("T2");
	tmpItem2.setValue("test2");
	tmpItem2.addChangedHandler(new ChangedHandler() {
		@Override
		public void onChanged(ChangedEvent event) {
			tmpItem2.redraw();
		}
	});
	DynamicForm tmpForm = new DynamicForm();
	tmpForm.setWidth100();
	tmpForm.setHeight100();
	tmpForm.setItems(tmpItem1, tmpItem2);
	addMember(tmpForm);

Steps:
- focus field T2, e.g. move to the last position in text
- press <BACKSPACE>
- changed handler is invoked
- all fields are cleared and JS exception "Incorrect function" is thrown.

Uncaught JavaScript exception [Incorrect function.] in http://........../client/sc/client/language/Class.js, line 1682

Tested on:
Win 8.1
IE11
SmartGWT-4.0p, SmartClient Version: v9.0p_2014-03-02/LGPL Development Only (built 2014-03-02)
and
SmartGWT-4.1p, SmartClient Version: v9.1p_2014-05-31

We have to enforce IE11 into "Document mode 10" in some cases and then we are getting into troubles when DynamicForm redraw is executed.
It seems, that FormItem._IESelectionStuck() returns TRUE, but "document.selection.clear();" called after fails with exception.
Exception is not catch and form redraw is interrupted.
Is it possible to fix it?
Thanks!

[Isomorphic]

Hi Martin

RE this:

We have to enforce IE11 into "Document mode 10" in some cases and then we are getting into troubles when DynamicForm redraw is executed.

Once we turn on Document mode 10 using the f12 developer tools on IE11 we can reproduce the problem with your sample.
This is not a supported mode, and you're hitting a bizarre native bug where the native document.clear method exists but executing it leads to this reported error.

We'll add a try...catch block around this call to trap this particular error but it is likely you'll run into other bugs running in this mode which wouldn't occur in supported modes.

Regards
Isomorphic Software

[millzee60]

Have you seen this?

http://msdn.microsoft.com/en-gb/library/ie/ms535869(v=vs.85).aspx

document.selection is not supported in IE11, you need to use document.getSelection()

[shresthg_des]

I am hoping for some follow up reply this thread as I am also facing similar problems

Thanks

[Isomorphic]

This issue should already be resolved in the 9.1p and 10.0d branches.
If you're still seeing problems here, can you confirm whether you're using the latest nightly build? If so we may need more information to reproduce the issue.

We'll also back-port this fix to 9.0p (will show up in the next nightly build - July 12 - in that branch)

Regards
Isomorphic Software

[shresthg_des]

Following are the details of the nightly build, the browser and the error:

1. Nightly build - SmartClient_v91p_2014-05-28_Pro

2. Browser - IE11

3. Error seen - ISC_Forms.jsUnspecified error.

Can you please let me know what extra information that is been expected here?

[Isomorphic]

As we noted, the issue is already resolved - now in all 3 major branches (9.0p, 9.1p and 10.0d).
To ensure you have the fix, you need to upgrade to the latest nightly patch build (builds available here).
If you continue to see a problem here let us know.

Also a little background on the fact that document.selection is not supported in IE11 (as noted here) - this particular piece of code is a workaround for a bug which occurred in older versions of IE and doesn't really apply to IE11, and as such it is appropriate for us to be using the older supported API to access document.selection directly.
The try..catch block will avoid this from causing a visible error in the 9.0p and 9.1d branches and in the mainline development branch (10.0d) a conditional exists such that this particular code flow won't even be executed in IE11.

Regards
Isomorphic Software

[shresthg_des]

Thanks! Seems to have fixed the issue.

[ispasov]

What about SmartGWT 3.1p?

Hi Isomorphic,
Will this issue be fixed in SmartGWT 3.1p branch?

I am trying with the build from 10.Aug.2014 (yesterday) and I see the wrong verification there.

ISC_Forms.js, Line 853:

 
isc.A.$100a=function isc_FormItem__IESelectionStuck(){
  if(!isc.Browser.isIE)return false;
  try{
    var _1=document.selection?document.selection.typeDetail:null
  }catch(e){
    this.logDebug("Internet explorer native 'stuck focus' state detected");
    return true
  }
}

Then this call on Line 911 fails:

if(this.$100a()){document.selection.clear();....}

We would be grateful if you include the patch in a 3.1p version; This breaks a critical workflow in our system, and if you say that there is not going to be an official patch, we'd have to wrap it the ugly way.

(moved the reply to a new topic in the correct forum (smartGWT))