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)
Tracking
()
VERIFIED
FIXED
M12
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 ;-)
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M12
Assignee | ||
Comment 1•25 years ago
|
||
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.
Comment 2•25 years ago
|
||
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).
Comment 3•25 years ago
|
||
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.
Reporter | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 5•25 years ago
|
||
marking this fixed and verified with mac 122111 (final final M12 bits).
Reporter | ||
Comment 6•25 years ago
|
||
verified
You need to log in
before you can comment on or make changes to this bug.
Description
•