Closed Bug 22255 Opened 25 years ago Closed 25 years ago

typing in ender text fields very slow on m12 builds

Categories

(Core :: DOM: Editor, defect, P3)

PowerPC
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: paulmac, Assigned: akkzilla)

Details

Typing has slowed down considerably since Friday's last M12 build. I've only noticed it on the Mac. It is easy to notice in mail compose, editor compose, url field, bugzilla description fields, etc. Akkana thinks some missing xul files may be the culprit. She will be sending me the files soon, so I can check them out. Note: leaf types slow enough he almost doesn't notice ;-)
Status: NEW → ASSIGNED
Target Milestone: M12
This is caused by taking hyatt's patch without my associated platform xul files which it depends on. This problem doesn't happen in the tip, where the platform files were checked in before hyatt's changes using them. Paulmac says that installing the mac platform xul files cures the problem. The files which need to go along with the hyatt patch are: mac/platformBrowserBindings.xul mac/platformEditorBindings.xul mac/platformInputBindings.xul mac/platformTextAreaBindings.xul unix/platformBrowserBindings.xul unix/platformEditorBindings.xul unix/platformInputBindings.xul unix/platformTextAreaBindings.xul win/platformBrowserBindings.xul win/platformEditorBindings.xul win/platformInputBindings.xul win/platformTextAreaBindings.xul It's up to the PDT committee (or whoever is making the decision) whether or not to take these files.
I would consider taking the files... but I thought I'd chime in with details from my observation of the bug (paulmac gave me a demo). When you type, the composer is "slow" to respond with the appearance of a keystroke. Worse yet, if you touch type at any reasonable speed, the system will fall behind progressively further as you type away. Paul is a resonable typist, and quickly got the Mac he was working on to be roughly 15 characters behind in the course of typing an 80 character line. Note that this does not make the product unusable, it is a bother, and will surely have a larger impact on the slower machines (and machines with poor file systems :-( ). If I had to guess, based on Akkana's proposed checkin, I'd say that after each keystroke, seamonkey tries to figure out how to handle the characters, and realizes that it needs some sort of translation file. It then proceeds to "look for the file" once again for each character (not remembering that it was not available the last time). Compared to the page-down regression, this is small. On the other hand, if I had to take a risk, the risk of minimal testing after *only* including these files is probably small (as hinted at by Akkana).
Yes, the key binding code is supposed to cache the "miss" of the files, so that it doesn't keep trying to find them. Obviously that code doesn't work. Paulmac filed a bug on me regarding this issue.
for what it's worth, I spent a little time reading the code to understand what risk there might be in including the files, and I don't see any significantly scary code. It looks like it should work fine, and early testing on the tip (on windows for me) looks good.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
marking this fixed and verified with mac 122111 (final final M12 bits).
verified
You need to log in before you can comment on or make changes to this bug.