Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#14968 closed defect (fixed)

dijit.form.Textarea jumps around focus events and during typing

Reported by: Matt Lauer Owned by: Douglas Hays
Priority: undecided Milestone: 1.7.3
Component: Dijit - Form Version: 1.7.2
Keywords: Cc:
Blocked By: Blocking:


This bug can be easily reproduced with Dojo 1.7+ and does not exist with 1.6.1.

It is severe enough to not use Dojo 1.7+ because of our dependance on Textarea. It is also somewhat unclear where the cause of the problem is, but a decent chunk of code related to height properties was stripped out of the Textarea.js in the 1.7+ releases.

To view problem:

  1. Select the Textarea tab
  2. Copy/paste all the dijit.form.Textarea Lorem ipsum so the Textarea grows well beyond the visible height. Do not click out of the Textarea.
  3. With the cursor at the bottom of the extended Textarea click out of the Textarea and it automatically jumps to the top of the tab frame or Textarea.
  4. Scroll back down to anywhere in the Textarea and click. It will jump to the top again, but the cursor will be placed correctly.
  5. Scroll back down to find cursor and type any characters and the Textarea will jump between the location of the cursor and the top of the page on every key entered

Try the same set of steps on with Dojo 1.6.1 and there is no jumping:

1.6.1 behaves normally. 1.7+ does not.

Attachments (2)

14968.patch (1.3 KB) - added by Douglas Hays 10 years ago.
possible fix
14968_2.patch (1.4 KB) - added by Douglas Hays 10 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 10 years ago by Matt Lauer

Also it is browser and OS independent. Updated versions of FF, Chrome, and IE all have the problem in Windows and at least FF and Chrome on OSX.

comment:2 Changed 10 years ago by Douglas Hays

Milestone: tbd1.7.3
Status: newassigned

started with [23959]

Changed 10 years ago by Douglas Hays

Attachment: 14968.patch added

possible fix

comment:3 Changed 10 years ago by Douglas Hays

laue0095, can you try out the attached patch (against trunk)? I hopefully fixed the problem on Firefox and Chrome but I couldn't get IE to fail on 1.7.2 (it doesn't take the needsHelpShrinking code path that I fixed). What IE version are you testing with?

comment:4 Changed 10 years ago by Matt Lauer

The patch appears to work on latest versions of Firefox and Chrome on Windows 7. I'm using IE9 (and testing in IE7 and IE8 mode often as well). IE7-9 all jump the to top of the Textarea and back to the cursor when the Textarea gets focus. That seems to be IE's only issue with this bug. IE does not jump when typing or growing, only when the Textarea gets focus.

Last edited 10 years ago by Matt Lauer (previous) (diff)

comment:5 Changed 10 years ago by Douglas Hays

Resolution: fixed
Status: assignedclosed

In [28133]:

Fixes #14968. Make use of minHeight when shrinking the height to prevent unwanted scrolling. Don't focus widgets on mouseup if they already have focus to prevent IE fromm jumping to top temporarily.

comment:6 Changed 10 years ago by bill

Resolution: fixed
Status: closedreopened

Starting with [28133] Dialog_mouse.html fails on IE8 with a test timeout on the "cancel dialog" test.

comment:7 Changed 10 years ago by bill

Likewise, form/robot/ValidationTextBox also started failing with that checkin.

Changed 10 years ago by Douglas Hays

Attachment: 14968_2.patch added

comment:8 Changed 10 years ago by Douglas Hays

proposed fix attached

comment:9 Changed 10 years ago by bill

Your patch is apparently handling the case where a focus occurs between mouse down and mouse up. I'm not sure what would cause that. Perhaps it's the default action of the mouse down? Maybe you can add a comment for that.

But anyway, after the patch the tests are running for me.

Also, this comment should presumably be removed since the corresponding code is no longer there:

// IE exhibits strange scrolling behavior when focusing a node so only do it when !focused.

comment:10 Changed 10 years ago by Douglas Hays

In [28181]:

Refs #14968. If mousedown causes focus before mouseup, don't attempt to refocus.

comment:11 Changed 10 years ago by Douglas Hays

Resolution: fixed
Status: reopenedclosed

comment:12 Changed 10 years ago by Matt Lauer

I have been working with the Dojo 1.7.2 base including both of the patches on this ticket. I have noticed two things which may or may not be related to the original ticket's problem.

I included a demo page because it will display problems nicely. Load this page in FF, IE, and Chrome/Safari?: (edit: made static demo link)

At the bottom of that page you'll find two declarative dijit.form.Textarea's:

<textarea name='post_text' id='post_text' data-dojo-type='dijit.form.Textarea' data-dojo-props="style:{width:'100%','min-height': '150px'}"></textarea>

<textarea name='post_text2' id='post_text2' data-dojo-type='dijit.form.Textarea' data-dojo-props="style:{width:'100%}"></textarea>

Two problems exist (with both textareas):

  1. Firefox does not render the min-height properly. I don't know if that is FF's fault or the dijit's fault. But we need (would really like) an empty/new textarea to be taller than the 2 lines that FF defaults to. This would make it more obvious to users what the textarea is for (typing a long reply). Chrome, IE7-9, and Safari all render the min-height fine.
  1. Webkit browsers Chrome & Safari experience dramatic key lag when typing in this box when the height of the textarea is less than or equal to the min-height property.

FF lags, too, but not as visibly. IE by far uses the least amount of CPU when typing or the textbox is growing. My guess is there are way too many resize function calls being made in non-IE browsers when a user types in a textarea. When adding the min-height setting in Webkit browsers, the problem is amplified and it goes over a visual threshold which makes the key lag very apparent.

To test this, I held down one so it repeatedly entered a character. These are my CPU utilizations for a 1.5 yr old computer:

  • FF uses 20-60% cpu
  • Chrome uses 35-60% cpu
  • Safari uses ~60%, sometimes dipping to 30%
  • IE9 uses uses less than 15% cpu

Chrome was also tested on a Fall 2011 MacBook? Pro... same keylag.

So, to summarize: IE7-9 all perform beautifully with these declarative dijit.form.Textarea's. The min-height appears correctly, the textarea resizes, and hardly uses any CPU when typing or resizing. FF doesn't display the min-height properly. Chrome/Safari? lag horrendously when typing when the textarea height is less than or equal to the min-height setting. FF suffers from high CPU but it is not a visible problem, like in webkit.


Last edited 10 years ago by Matt Lauer (previous) (diff)

comment:13 Changed 10 years ago by bill

Since those problems are probably unrelated, and since this ticket is already closed, please open two new tickets.

comment:14 Changed 10 years ago by Douglas Hays

In [28253]:

Refs #14968. Eliminate Chrome performance issue by progressively shrinking faster instead of 1px at a time.

comment:15 Changed 10 years ago by Douglas Hays

laue0095, can you verify the CPU utilization improvement with the latest commit?

comment:16 Changed 10 years ago by Matt Lauer

Yes there was an improvement. It improved enough to remove the staggering typing effect that was happening in Chrome.

Both Chrome and FF average 30-50% CPU utilization during continuous keypress/typing which is much higher than IE but isn't too noticeable to the user. FF/Chrome also do not stagger when the computer is other load from other sources (applications loading/processing).

I have also stripped down the demo page ( to make sure it was not my code/styles that was creating the textarea min-height problem in FF (it isn't). I will create a new ticket for that.

comment:17 Changed 10 years ago by Douglas Hays

In [28261]:

Refs #14968. Speed up shrink on Chrome/Firefox?.

comment:18 Changed 10 years ago by Douglas Hays

In [28290]:

Refs #14968, #13341. Move _onMouseDown processing to _onFocus(by=mouse) to better align with the focus manager's current behavior of invoking _onFocus before onfocus and before onmousedown.

Note: See TracTickets for help on using tickets.