View Full Version : ExtJS 4.x Password Field: Erratic behavior when deleting entered data

11 May 2014, 3:56 AM

I have a window >> form with text, combobox and password fields.

When this window>>form is called as the default window (no other active view), all fields work fine (enter, delete, reset, submit, etc.).

But when this windows>>form is called when there are other views working at the background, I noticed that all fields works well when entering and deleting field entries...... except for the password-type text field.

The behavior is okay when keying-in entries.... but when I started backspacing.... everything works except the browser hangs (script taking too long to execute)... at the last character.

The password field is without a "blank field validation".... and without an "empty text" entry.

I hope to find the answer soon.

11 May 2014, 10:11 AM
Is it consistent across browsers?

If it's taking a long (but finite) time you should run it through a profiler. If it seems to be running indefinitely try pausing JavaScript execution and see what it's up to.

17 May 2014, 12:46 AM
It fails in Chrome 29.0.1547.76

It's working in Firefox 29.0.1

It hangs indenfinitely until Chrome shows the "oh snap..." message

17 May 2014, 3:20 AM
You're going to need to attack this with breakpoints.

The first thing to try is clicking the Pause button immediately after you delete that last character. Sometimes that works, sometimes it doesn't. If it does, it gives you a foot in the door to analyse what's going on.

If that doesn't work, if you have any suspicions about which bit of your code may be to blame then shove breakpoints in there.

Failing that, try using Chrome's 'Event Listener Breakpoints'. My guess would be 'Keyboard -> input' is your best bet but you'll have to make observations and react accordingly.

From trying this myself I notice that ExtJS's main handler for 'input' is delayed, so you'll have to add a breakpoint into the deferred function if you want to step into that.

17 May 2014, 5:55 AM
I got the following:
1. the screen freezes for 2.3 minutes then cleared the password field afterwards.
2. events registered (during delete button press) are mostly keydown/keyup, timer fired, and functional call to extjs.
3. however, on the last keyup (delete of last letter), the following were triggered: Function Call x 2, Function call (ext-all.js:21), install timer (ext-all.js:21), function call (content Script.js:342), Timer Fired (ext-all.js:21) then remove timer (ext-all.js:21).

contentScript.js:342 is as follows:

document.body.addEventListener('keyup', function(event) {
//If they just let go of the shiftkey, check for selection
if (event.keyCode == 16) {

Instead of backspacing(delete button), I also tried to highlight the whole text in the password and press an alpha key.... it also freeze at that scenario.



17 May 2014, 6:13 AM
You should use ext-all-dev.js or ext-all-debug.js for debugging, or even load the files from source if your browser struggles to debug the larger files.

What is contentScript.js? Is that your code? Does removing that code improve the situation?

22 May 2014, 2:17 AM
contentScript.js is an ext.js code (not mine).

I'm using Architect-3 with Extjs 4.2.1. I can't figure out how to set SA to use ext-all-dev.js instead of the ext.js. Do you have a good read/thread regarding this?

Anyway, to help Sencha troubleshoot this problem, here is the complete scenario:

NOTE: this problem shows up in Chrome Version 29.0.1547.76

2. have this FORM have its own viewport (no other panels).
3. Type in 5 characters then delete all 5 characters.
4. There is no problem at this point.

5. Next, put FORM inside a panel grid.
6. Add toolbar with 3 buttons.
7. Add gridpanel with 1 column
8. At this point, the form is inside a panel with more than 5 other components (see 6 & 7)
9. Type in 5 characters then delete all 5 characters.
10. PROBLEM: won't delete the first character until about 2 minutes 30 seconds.

11. Next, I changed type PASSWORD to type TEXT
12. Type in 5 characters then delete all 5 characters.
13. Hey, no problem.

1. It might have something to do with the masking of characters (text to bullet).

I hope someone could have a look at this.

Thanks in advance.