Long pause when deleting character from PasswordItem

[Osirium1]

Browser: Chrome27 on OSX and Windows XP/Vista/7

SC versions tested: SNAPSHOT_v9.0d_2013-05-29; and 8.3p from 2013-05-29

To re-create:

1. Type n characters into a PasswordItem
2. Press backspace n-1 times
3. Observe that each character deletes imperceptibly fast
4. Press backspace to delete the single remaining character
5. Observe that the character appears to take longer to delete

The 'heavier' your SmartClient application, the longer that last character takes to disappear from the PasswordItem. So, if you run the code below with no other SC components on the screen, then you almost can't perceive a difference between the pauses, but if open up the http://www.smartclient.com/#showcaseApp and click around a bit (perhaps expand the tree, click an entry to populate the Office Supply Items grid, click the 'Edit' tab of the item, etc) then the pause becomes more noticeable.

isc.Window.create({items:[isc.DynamicForm.create({fields:[{name:"test",type:"password"}]})],autoSize:true,autoCenter:true}).show()

Our application allows the user to open tabs and, consequently, with many tabs open (even though they are not visible) Chrome can hang for up to 10 seconds when deleting that final character!! It is unusual that this one operation is so slow, when the rest of the app is responsive even with that many tabs open.

When looking in Chrome's Timeline profile tool you can see that there are two different waterfalls for the different scenarios.

This is for deleting one of the n-1 characters:

[ATTACH]5732[/ATTACH]

And this is for deleting the final character:

[ATTACH]5733[/ATTACH]

As you can see, I had to chop the timeline but former is well under 0.01s whereas the slower one takes almost 0.4s.

I wasn't sure why there would be the extra Layout and Recalculate Style events just because you're deleting the final character of the password, but it seemed consistent over several captures of the waterfall.

I also looked at the SC Console log and you can see the difference.

Deleting one of the n-1 characters:

11:22:43.283:KDN8:INFO:EventHandler:keyDown event with Canvas target: [PasswordItem ID:isc_PasswordItem_4 name:foo], native target: [INPUTElement]{name:foo}
11:22:43.283:KDN8:DEBUG:EventHandler:Event 'keyDown' bubbled to top
11:22:43.283:KDN8:INFO:EventHandler:keyPress event with Canvas target: [PasswordItem ID:isc_PasswordItem_4 name:foo], native target: [INPUTElement]{name:foo}
11:22:43.283:KDN8:DEBUG:EventHandler:keyPress not handled natively
11:22:43.283:KDN8:DEBUG:EventHandler:Bubbling for event 'keyPress' cancelled via STOP_BUBBLING return value by target: [DynamicForm ID:isc_DynamicForm_22]

.008s gap

11:22:43.291:INP9:INFO:RPCManager:sendQueue called with no current queue, ignoring
11:22:43.394:KUP0:INFO:EventHandler:keyUp event with Canvas target: [PasswordItem ID:isc_PasswordItem_4 name:foo], native target: [INPUTElement]{name:foo}
11:22:43.394:KUP0:DEBUG:EventHandler:Event 'keyUp' bubbled to top

Deleting the final character:

11:22:48.613:KDN1:INFO:EventHandler:keyDown event with Canvas target: [PasswordItem ID:isc_PasswordItem_4 name:foo], native target: [INPUTElement]{name:foo}
11:22:48.614:KDN1:DEBUG:EventHandler:Event 'keyDown' bubbled to top
11:22:48.614:KDN1:INFO:EventHandler:keyPress event with Canvas target: [PasswordItem ID:isc_PasswordItem_4 name:foo], native target: [INPUTElement]{name:foo}
11:22:48.614:KDN1:DEBUG:EventHandler:keyPress not handled natively
11:22:48.614:KDN1:DEBUG:EventHandler:Bubbling for event 'keyPress' cancelled via STOP_BUBBLING return value by target: [DynamicForm ID:isc_DynamicForm_22]

.733s gap

11:22:49.347:INP2:INFO:RPCManager:sendQueue called with no current queue, ignoring
11:22:50.062:KUP3:INFO:EventHandler:keyUp event with Canvas target: [PasswordItem ID:isc_PasswordItem_4 name:foo], native target: [INPUTElement]{name:foo}
11:22:50.062:KUP3:DEBUG:EventHandler:Event 'keyUp' bubbled to top

Many thanks!

[Isomorphic]

Thanks for putting this together in painstaking detail.

The thing is, experience has shown that a deep investigation into something like this very often reveals a native browser bug with an exotic just-barely-possible workaround, which we then implement just in time to have that bug fixed by the browser vendor, leaving everyone wishing we'd fixed some other bugs instead..

For this reason we are going to let this sit for a while and see if similar symptoms arise for others in a situation that has higher severity.

But thank you for taking the dive to analyze this and share your findings - it may well help solve this issue in the future.

[Osirium1]

I understand. I do hope the priority bumps up, because our application asks for a lot of passwords and if the user makes a mistake, the wait can be painful!!

As a final thought in case you do come back to this:

<form>
  <input type="password"/>
</form>

The above input box works perfectly on the same page as the troublesome PasswordItem.

Also, in addition to having a long pause when deleting the final character, if you select all the characters in the PasswordItem and press backspace, you will experience a similar length of long pause.

[Osirium1]

For anyone trying to re-create this in the future, this code should make a substantial long pause:

for (var i=0;i<10;i++) {
  var data = [];
  for (var j=0;j<250;j++) { // When setting j<251, the pause suddenly reduces
    data.push({foo:"Item " + j});
  }
  var l = isc.ListGrid.create({
    fields:[{name:"foo"}],
    data:data
  });
  l.show();
  // l.hide();  // hiding makes no difference to long pause
  // l.clear(); // clearing does remove long pause
}

isc.Window.create({items:[isc.DynamicForm.create({fields:[
  {
    name:"pass_test",
    type:"password",
    defaultValue:"aa"
  },
  {
    name:"text_test",
    defaultValue:"aa"
  }
]})],autoSize:true,autoCenter:true}).show();

clearInterval(isc.History.$4); // $4 = _historyTimer; this tidies up the waterfall but makes no difference to the length of the pause

Note the magic number of 251 data rows that suddenly reduces the pause. You can then crank i<10 up to i<100 and still have a shorter pause than with i<10 & j<250.

Finally, note that clear the ListGrid after drawing it exhibits as little a long pause as if you had not drawn the ListGrid at all. Probably to be expected!

[Isomorphic]

Probably what you're experiencing there is that the default setting for drawAllMaxCells means that at 251 records we would switch over to incremental rendering, causing a reduced DOM.

But yeah, this is even more evidence for this being a weird native bug in Chrome. In terms of what SmartClient is doing with these components, they are totally unrelated and could never affected each other in this way.