23868 - unselecting large table... browser unusable for many seconds

Status: VERIFIED WORKSFORME

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

Description

[ttb]

when i view all the bugs left for M13 and
i scroll down to the bottom and start highlighting all the text
and drag it up
then i unselect it at the top.. the browser becomes unusable for many seconds
this seems to because of the very slow highlighting/unhighlighting and
because there is so much stuff highlighted it takes along time for
it to be done unhighlighting.
i could reproduce this many times
my build id: 2000011110

Comment 1

[Sean Richardson]

[e-mail], could you please identify the Platform and OS
you were using? There is an existing selection performance bug filed against
the Mac version of Mozilla, bug 5761, "[PP] Selection and display is unusably 
slow in browser", but I'm not sure this is a DUP of it. This isn't slow on
NT, so it would help to know what version you found bogged down. Thanks.

Tested this using a search for *all* 187 selection bugs - the URL above
now points to that bug list, as a standard for comparison.
On WinNT, there was a perceptible delay after clicking to unselect before
the selection was cleared, but it lasted less than half a second. 

In any case the CPU meter did not peg, and I was unable to try the UI before 
the selection cleared. Clicking on a link inside the selection loaded the 
linked page before the selection visibly cleared, contrary to expectations
from NN 4.7 - is this important enough to file a new bug for?

It does take many seconds for the drag-selection to finish, but I'm sure 
we're all aware of the perils of super-fast drag-selection. Still, it felt
slow.

Tested with: 2000-01-25-08-M14 nightly binary on Windows NT 4.0

Comment 2

[ttb]

it was Linux 2.3.38 glibc 2.1 

Comment 3

[rubydoo123]

how large was the list? Were there 100, 200, ?? bugs in the list? That would 
help so we could try to narrow down the issue. Thanks

Comment 4

[rubydoo123]

I used build 2000012812 on win95 -- a 166MHZ system, ran a query with 283 bugs 
in the list. I did several selects and deselects and could not reproduce this 
problem. I tested on Linux, using the 1/25 build and couldn't dup this with a 
bug list of 1893. Marking this as a worksforme. If you can reproduce this, then 
please reopen but please add the number of bugs that were in your list. Couldn't 
test on Mac using today's build -- for some reason the app would crash when 
select submit.

Comment 5

[ttb]

using Linux with the 2000 01 28 13 build i can reproduce this bug as follows:
goto bugzilla
query existing bugs
select all platform's and all Opsys's
then select target milestone as 14
click submit
scroll down to the bottom of the list
click and start selecting text and keep scrolling up and selecting until
your at the top.. then click somewhere in the browser window to start
the deselecting of the highlighted text.. the browser stops being usable
for along period of time.. i had switched out of X while this was happening
and when i returned i got a Gdk-Error: fatal IO error 104
and the X server core dumped.

Comment 6

[leger]

Clearing WORSKFORME resolution due to reopen.

Comment 7

[rubydoo123]

used version 1.31.15 on a linux redhat 6.0 -- running on HP Vectra, ran a quesry 
with status-nothing selected, resolution- nothing selected, 
platform-all, opsys-all, 
priority/severity/email(1)/email(2)/program/version/component - nothing 
selected, milestone-m14 -- and ran query -- when result came back, scrolled to 
the bottom, selected from the bottom to the top, selected in the window to 
deselect, the deselection took a few seconds, and the app continued to act as 
expected.

Marking bug worksforme

Comment 8

[ttb]

using a 01 31 build on Debian 2.2 Linux 2.3.39 Xfree 3.3.5

going to bugzilla using default settings except for marking All for

op sys's and platforms and M14

clicking submit

scrolling down to bottom

then highlighting until the top

then clicking in the window to deselect

took mozilla 1 minute at 99% cpu (according to top)

to deselect the table and return to processing events.

this bug is STILL here. quit marking it as WORKSFORME please.

Comment 9

[rubydoo123]

when it stops working for me then I'll stop marking it works for me -- marking 
as such

Comment 10

[rubydoo123]

Some additional thoughts that may clear up the issue for in this particular 
case. Table functioanlity is still going on, tables are not complete. 
Performance and optimization work will not be done until after the table 
development is completed, which is slotted for m16. Even though tables are not 
complete and the performance tuning has not been done, I can't replicate your 
problem using 3 different linux boxes -- if we can't replicate it, then we can't 
debug it, which means we can't fix it. The last test we did, we had nearly 2000 
lines and it took less than 15-20 for the entire process -- meaning from 
scrolling to the bottom, scrolling to the top, deseelcting the selection and 
being able to continue with the app. I realize this has got to be frustrating 
for you, and I'm sorry. But, we can't reproduce your issue.

Comment 11

[Sean Richardson]

It seems possible that bug 26502, "Linux rendering performance is at least 5x 
slower than windows", could be relevant here... the X bog described there could 
hit one X server much harder than another.
 

Comment 12

[Eli Goldberg]

Rubber-stamping as Verified/WORKSFORME.

Per sidr's highly relevant comment (thanks!), suggest holding off on this bug 
until 26502 is fixed, which has a TFV of M14.