Closed
Bug 35884
Opened 25 years ago
Closed 25 years ago
dialogue box (alert) extremely slow
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
People
(Reporter: spam, Assigned: joki)
References
()
Details
2000-041309 and 041316, M16
when clicking link "Other Nightly Builds" it takes up to over 80 seconds before
the dialogue box appears with "Are you sure..." etc.
Worse yet: Dismiss the box and click again: It takes 80 seconds once again, in
worst case.
There are three types of "misbehaviour" involved.
Steps to reproduce:
1: Exit all of Mozilla and restart. Do not open other windows first.
2: Go right to http://www.mozilla.org/binaries.html
2A: Click link. Keep cursor still over link after click: Dialogue pops up after
approx. 80 sec.
2B: Click link. Move cursor away from link out on page: pops up after 15 sec.
2C: Click link, move cursor away from link and over another link or two, so the
cursor changes shape to pointing hand: box pops up after "only" 4-5 sec.
--
Discovered that when the master password box has been open first, the popup-box
gets initiated correct, and is remembered for later use. The above procedure
does not provoke the bug to happen then.
On NS4.7 the dialogue box appears instantly. Even in "best case" the dialogue
box in Moz is slow, it takes a long second on a P120.
I first reported bug 35796 about this which i set invalid and couldn't reopen.
After a new install and profile the bug was still reproducable. So resubmitting
it here, with clearer walkthrough.
This bug may be Linux specific: sidr@albredo.net tested above steps on NT and
could not reproduce: There the box popped up in 1/4 sec or less.
Updated•25 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 1•25 years ago
|
||
This looks like it could be a DUP of bug 35248, "onClick fires on blur,
not button up".
Summary: dialogue box extremely slow → dialogue box (alert) extremely slow
35248 is about something entirely different, you got the bug# wrong.
But even so:
Note that his box-bug does NOT happen if a password dialogue has been open
first. Then things work OK'ish, and actually fires on a onClick. (Still slow but
way faster than 80 sec.)
Comment 3•25 years ago
|
||
Sorry 'bout the transposition -- "onClick fires on blur, not button up"
is bug 35284. You might want to try the steps there after using a password
dialogue, that ought to help determine if there is any commonality.
As i understand bug 35284 something IS supposed to happen when you click add
page, and then in the *next* menu there's a "freeze" unless you wriggle. Tried
to reproduce it but it's not a very good testcase since nothing even happens
when i click "add page" - independant of "mouse-wriggle" or not.
Tested attachment in bug 35284 - it seems to be the same bug so i'm marking
duplicate. The button doesn't appear "Unpressed" again till after the popup is
dismissed.
*** This bug has been marked as a duplicate of 35284 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
verified dup - the fix for 35284 fixed it. Forgot this bug.
Now using 2000-072113: there is no excessive lag from link is clicked till box
appears and hasnt been for a long while.
Status: RESOLVED → VERIFIED
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•