117916 - Successive Indents are handled slower as more are entered

Status: NEW

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

Description

[Jay Farrell]

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.

Comment 1

[Asa Dotzler [:asa]]

->Editor:Composer 

Comment 2

[Syd Logan]

-->cmanske

Comment 3

[Charles Manske]

Core editor DOM manipulation performance issue.

Comment 4

[kinmoz]

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.

Comment 5

[kinmoz]

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.

Comment 6

[sujay]

Jay, please let us know if this is fixed for you...thanks.

Comment 7

[Jay Farrell]

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.

Comment 8

[Colin Blake]

Jay, what you are running is "rc1". If you say that magic word, people should 
understand exactly what it is you have.

Comment 9

[kinmoz]

I think it was fixed before rc1, in any case it's fixed on the trunk and 1.0 
branch.

Comment 10

[michael wendell]

Verified on the 05-07 trunk and 1.0.0 branch builds.

Comment 11

[Jay Farrell]

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?

Comment 12

[Colin Blake]

Jay, did you try on Linux RC2? Maybe the problem you're seeing isn't fixed!

Comment 13

[Jay Farrell]

Yes, the problem still existed on the Linux Rc2 build from 2002051009

Comment 14

[Jay Farrell]

reopened 

Comment 15

[Joe Francis]

i can't repro any significant perf problem but i did get a crash.  users aren't
very likely to hit this though.

Comment 16

[Joe Francis]

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.

Comment 17

[Joe Francis]

[ushing these out as far as bugzilla will let me.  I'll pull them back as I work
on them.

Comment 18

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.