IE11 bug with startEdititng and MenuItem

[SimonF]

Hi there,

I found a bug if you add click a MenuItem which adds an record to listgrid. If you are clicking at the side of the MenuItem, the new record is correctly added and the editing starts.
In IE11 the text in the listgrid is marked but the focus is staying on the menu. It seems to happen if you're clicking the side of the button (at least this i how i could reproduce it)

This behaviour is reproducable in IE11 with the latest nightly (v10.0p_2015-03-17). Before moving the mouse fast, i tried to hit several keys ;-)


this is the code to reproduce this:

isc.ListGrid.create({
	"ID" : "theMainGrid",
	"width" : "100%",
	"height" : "100%",
	"selectionType" : "multiple",
	"canEdit" : true,
	"editEvent" : "doubleClick",
	"autoSaveEdits" : false,
	"selectionProperty" : "isSelected",
	"fields" :
	[{
			"name" : "textField",
			"title" : "title",
			"type" : "text",
			"width" : "280",
			"canEdit" : true,

		}
	]
});
isc.MenuButton.create({
	"ID" : "addMenuButton",
	top : 100,
	left : 100,
	"title" : "new",
	menu : isc.Menu.create({
		"selectionType" : "single",
		"canEdit" : false,
		"data" :
		[{
				"click" : function (p1, p2, p3, p4) {
					isc.showPrompt('Loading...');
					theMainGrid.setData([{
							"textField" : "new element",
							"mainGridElementIndex" : "1"
						}
					]);
					theMainGrid.selectSingleRecord(theMainGrid.data.find("mainGridElementIndex", 1));
					theMainGrid.startEditing(theMainGrid.data.indexOf(theMainGrid.getSelectedRecord()));
					isc.clearPrompt();
				},
				"title" : "click here"
			}
		]
	})
})

Best Regards

[Isomorphic]

This is likely a side-effect of this issue:
http://forums.smartclient.com/showthread.php?p=129949#post129949
Please try the next nightly build and see if the problem persists for you.

Regards
Isomorphic Software

[SimonF]

I've retested it with the latest nightly v10.0p_2015-03-19.
Issue still exists and reproduced again after 5 seconds.

It's quite easy with the code above to reproduce you only have to click at the border of the MenuItem (Move the mouse until the pointer-cursor appears, then click). Notice the dashed border after the klick.

[Isomorphic]

Ok - we'll take a look

Thanks
Isomorphic Software

[Isomorphic]

This issue is due to a native timing difference between Internet Explorer and other browsers. In IE, when an element receives native focus (from a user-action such as click or tab keypress, or from a programmatic focus() call), the browser natively fires focus/blur notifications asynchronously in a new thread after the current thread of execution completes, while in all other browsers it is fired synchronously.

SmartClient uses these native focus/blur notifications to track which widget currently has focus.
In this particular case this leads to an odd interaction with the "prompt" clickMask which ultimately causes us to leave focus on the menu item when the prompt is hidden rather than shifting it to the edit-item in the grid as we would in other browsers.

The easiest way to handle this would probably be to modify your application code to hide the prompt before calling 'startEditing' on the grid. It's occurring in the same thread so this should have no user-visible impact.

Regards
Isomorphic Software

[SimonF]

thanks for the suggested workaround.
In our application the user can only do one interaction at a time. Because of possible changes after an event, a button could be disabled, so we have to block the gui for the user.

For this reason we are using the prompt. Your workaround seems to be an "easy" fix, but this would mean, we have to move the logic for removing the prompt away from client side, and instead have to move the call the clearPrompt in our server-response of every event. I think the clearPrompt should be located in the client after receiving the result of the event.

There would also be the possibility to clear the prompt before executing the response of the event, but not knowing how long js needs to update the components opens the chance that certain buttons may be clicked by the user, which should be disabled at that time.

Despite i'm aware that this is an internet explorer problem, it seems there is no "clean" solution to that problem.

[Isomorphic]

Sorry, we don't follow how this could impact your wider application architecture.

In a nutshell, if your code is going to move keyboard focus somewhere (such as with a call to startEditing()), clear the prompt first.

This makes basic sense, since it's meaningless to move focus while the UI is blocked.

Put another way, startEditing() with a prompt showing is essentially an invalid call, even though it happens to work anyway on some browsers.

[SimonF]

I have found a solution to call startEditing after the prompt is cleared.

Thanks for the hint to not call startediting while the prompt is visible.