From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) BuildID: 20011205 If you hold down the increase indent keyboard sequence for about 10 seconds, they are processed in about 5 seconds of letting go of the increase indent keys. But if you hold it down for 20 seconds, it took about 20 seconds to process. Reproducible: Always Steps to Reproduce: 1. I was following the Increase/Decrease indent section of http://www.mozilla.org/quality/browser/front- end/testcases/composer/composer-menus.html When I decided to try holding down the increase indent keys "for a while" Actual Results: The longer I help down increase indent, the longer it took for them to be processed. At one point, I thought I had locked up my machine since it took so long for the increase indents to be processed. Expected Results: I expect the results of the increase indent to return within a resonable timeframe This issue was witness by myself and Colin, who I'll add to the Cc list.
Assignee: asa → syd
Status: UNCONFIRMED → NEW
Component: Browser-General → Editor: Composer
Ever confirmed: true
QA Contact: doronr → sujay
Assignee: syd → cmanske
Target Milestone: --- → mozilla1.1
Core editor DOM manipulation performance issue.
Assignee: cmanske → kin
Component: Editor: Composer → Editor: Core
Target Milestone: mozilla1.1alpha → Future
I believe jfrancis fixed this already. I don't see the problem in my 05/05/02 TRUNK or MOZILLA_1_0_0_BRANCH builds.
Assignee: kin → jfrancis
Target Milestone: Future → ---
I couldn't find the bug I wanted to dup this against, so I'm just going to mark this fixed. Jay, try a more recent build.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Jay, please let us know if this is fixed for you...thanks.
We are re-running front-end tests on the latest release of Mozilla on OpenVMS, built 20020419. Will the fix be in that release? Your entries are dated 5/5, but you mention the 1.0.0 branch, which is what our version is based on.
Jay, what you are running is "rc1". If you say that magic word, people should understand exactly what it is you have.
I think it was fixed before rc1, in any case it's fixed on the trunk and 1.0 branch.
Verified on the 05-07 trunk and 1.0.0 branch builds.
Status: RESOLVED → VERIFIED
Responce was still extreemly slow if I held down ctrl-] for a 20 second count. I'm testing the OpenVMS RC2 build 20020513. Is it possible my build doesn't have this fix?
Jay, did you try on Linux RC2? Maybe the problem you're seeing isn't fixed!
Yes, the problem still existed on the Linux Rc2 build from 2002051009
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
i can't repro any significant perf problem but i did get a crash. users aren't very likely to hit this though.
Target Milestone: --- → mozilla1.2alpha
The days of having a half dozen milestones out in front of us to divide bugs between seem to be gone, though I dont know why. Lumping everything together as far out as I can. I'll pull back things that I am working on as I go.
Target Milestone: mozilla1.2alpha → mozilla1.2beta
[ushing these out as far as bugzilla will let me. I'll pull them back as I work on them.
Target Milestone: mozilla1.2beta → mozilla1.4beta
Assignee: mozeditor → nobody
Status: REOPENED → NEW
You need to log in before you can comment on or make changes to this bug.