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)

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 35284

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.)
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
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.