Opened 11 years ago

Closed 11 years ago

Last modified 8 years ago

#7742 closed defect (wontfix)

Textarea: has delayed keyboard input in Firefox 3.0.x, not Firefox 2.0.0.x

Reported by: Jonathan Bowers Owned by: Douglas Hays
Priority: high Milestone: 1.3
Component: Dijit - Form Version: 1.2beta
Keywords: Cc:
Blocked By: Blocking:

Description

Using Firefox 3, if you hammer on the keyboard in a Textarea, you will notice a significant delay in the text appearing in the widget. While not tremendously slow on very simple pages, the delay gets worse with a large number of widgets on the page.

However, using Firefox 2, this delay does not exist. If you try the same page using Firefox 2 (you can fake this by changing your general.useragent.extra.firefox setting in about:config in Firefox from "Firefox/3.0.1" to "Firefox/2.0.0.16") the delay is gone.

This looks to be something to do with the template string being different for Firefox 3 than for Firefox 2 as by merely changing user agent string, the problem disappears.

This can been seen here: http://download.dojotoolkit.org/release-1.2.0rc1/dojo-release-1.2.0rc1/dijit/tests/form/test_Textarea.html

Systems affected:

Firefox 3.0.x on Linux, Windows

Change History (6)

comment:1 Changed 11 years ago by bill

Owner: set to Douglas Hays
Summary: dijit.form.Textarea has delayed keyboard input in Firefox 3.0.x, not Firefox 2.0.0.xTextarea: has delayed keyboard input in Firefox 3.0.x, not Firefox 2.0.0.x

Hmm, you are right, I can reproduce this on mac too (if a type a bunch of characters, including newlines, there's a multi-second delay before all that I've typed shows up). And we could probably easily switch FF3 to work like FF2, using an iframe rather than a contentEditable div.

The problem is that doing so causes an a11y issue that you have to hit the tab key twice to get out of the textarea widget into the next one. (Another disadvantage is that it makes us keep maintaining that old FF2 iframe code path that we had hoped to get rid of eventually.)

So, should probably close this as "wont-fix", unless we can think of a way to have our cake and eat it too. Passing to Doug for consideration; Doug, maybe you have an idea that I haven't thought of?

comment:2 Changed 11 years ago by bill

Milestone: tbd1.3

Marking this for consideration for 1.3; maybe there's some optimization to be done. It doesn't seem like it should be this slow (regardless of whether it uses an iframe or a contentEditable div).

comment:3 Changed 11 years ago by bill

I can't reproduce on windows, using the red Textarea on test_Textarea.html. It did reproduce on mac though.

comment:4 Changed 11 years ago by Douglas Hays

Resolution: wontfix
Status: newclosed

I narrowed the problem down to the number of native INPUT tags that are on the same page. If there are none, then it is very fast and if you add a bunch of simple INPUT tags (even with no other attributes) then the typing speed slows down even more. So it seems to be more a problem with the browser.

comment:5 Changed 10 years ago by mvictory

Any chance this can be re-opened? We have an application that allows multiple "pages" to be open at a time which in reality means a page with MANY input fields. It can take multiple seconds just to set focus to a Textarea field. The problem does NOT occur in IE7 or FF2 so I assume it is the same issue.

comment:6 Changed 8 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.